Re: [tryton] About external module and README

2012-07-21 Thread Craig Barnes
On 20 July 2012 08:30, Cédric Krier cedric.kr...@b2ck.com wrote:
 On 20/07/12 07:46 +0530, Teagarden wrote:
 On 20-Jul-2012, at 1:54 AM, Cédric Krier cedric.kr...@b2ck.com wrote:

  On 19/07/12 22:03 +0200, Sergi Almacellas Abellana wrote:
  Why we don't add tryton.org (or the tryton foundation) in Package
  Index Owner and Package Index Maintainer to denote an official
  module? The rest of the modules will have it's own maintainer
  denoting that it isn't an official module.
 
  It makes sense to me. What do you think?
 
  Because it doesn't prevent name collision.

 Name collision seems to be the primary problem we are trying to
 solve. I agree with the issue and we are ready to move our modules
 to a *new* naming scheme too, and may be most of us in this
 community will too, but that doesn't really solve the problem because
 anybody could still create packages on pypi under the tryton namespace
 ? And if it is his *intention* to do it, we might have little or no
 influence over it either.

 We could have some way to put pression on the bad guys:

 - Bad advertising
 - Sue for using the Trademark Tryton
 …

 My preferred solution to the problem would be hosting our own pypi
 which serves the official modules and perhaps the community ones too.
 The package index could perhaps be regulated by a 'packaging sig',
 which could arbitrate on name clashes and disputes.

 I would prefer to not have to do that and stay in the Python community.
 But in the last resort, it is a solution.

This message on the gnu heath mailing list [0] is very timely, and
appropriate for this discussion.

Do you think package signing and verification would be a good idea on
pypi to help eliminate the question of is it an official package?

[0] http://lists.gnu.org/archive/html/health/2012-07/msg00021.html

-- 
Craig

'The first time any man's freedom is trodden on - we are all damaged.'
Jean-Luc Picard
()  ascii ribbon campaign - against html mail
/\

-- 
-- 
tryton@googlegroups.com mailing list





Re: [tryton] About external module and README

2012-07-19 Thread Raimon Esteve
2012/7/18 Cédric Krier cedric.kr...@b2ck.com:
 It is http://pypi.python.org/pypi?:action=browseshow=allc=551

I think the problem is modules are available in pypi site, not the module name

Raimon

-- 
-- 
tryton@googlegroups.com mailing list





Re: [tryton] About external module and README

2012-07-19 Thread Nicolas Évrard
* Raimon Esteve  [2012-07-19 18:20 +0200]: 

2012/7/18 Cédric Krier cedric.kr...@b2ck.com:

It is http://pypi.python.org/pypi?:action=browseshow=allc=551


I think the problem is modules are available in pypi site, not the module name


I disagree.
As I told you on twitter, we have two ways to denote tryton packages
in pypi:

- The classifier
- The name

I propose that names starting by 'trytond_' denote official tryton
packages. All other packages should be named just like people want as
long as they use the correct classifier then users of pypi will be
able to find them easily.

--
Nicolas Évrard

B2CK SPRL
rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
E-mail/Jabber: nicolas.evr...@b2ck.com
Website: http://www.b2ck.com/


signature.asc
Description: Digital signature


Re: [tryton] About external module and README

2012-07-19 Thread Cédric Krier
On 19/07/12 22:31 +0200, Sergi Almacellas Abellana wrote:
 Al 19/07/12 22:24, En/na Cédric Krier ha escrit:
 On 19/07/12 22:03 +0200, Sergi Almacellas Abellana wrote:
 Why we don't add tryton.org (or the tryton foundation) in Package
 Index Owner and Package Index Maintainer to denote an official
 module? The rest of the modules will have it's own maintainer
 denoting that it isn't an official module.
 
 It makes sense to me. What do you think?
 Because it doesn't prevent name collision.
 Your solution only prevents name collision on the official modules.
 The collision will exists always in unofficial modules.

Except if unofficial also follow a schema.
I think B2CK will publish his packages under the prefix b2ck_ because
it is the name of the project from where it comes.

 Let's take an example, if anyone create a package named trytond_hr,
 there are a lot of chances that one day or an other Tryton will have a
 module with the same name.
 We must see the trytond_ as a name space and this name space is
 devoted to Tryton.
 To tryton or to tryton related packages? IMHO makes more sense to
 tryton related packages.

When I say Tryton I mean the project/community.

 By the way having let say a package named b2ck_hr doesn't prevent it to
 install a module named hr.
 
 By the way, I did not yet see any good explaination why non-Tryton
 packages should be prefixed by trytond_ ?
 And I did not yet see any good explanation why Tryton packages
 should not be prefixed by trytond_?

- It brings confusion
- It will create name collision:
  We can expect in the long term that there will be more
  unofficial packages than official. So each time a new
  official package will be created, its name will part of a long
  process to find a free name (which could be not the more accurate
  one).

Finally, I would like to remember that if people wants to have a module
be part of the official modules. He should join the community and
follow the standard process:

- blueprint
- talks/mailing list
- codereview…

Otherwise, it could be feel as a hijacking of the project/community.

-- 
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric.kr...@b2ck.com
Website: http://www.b2ck.com/


pgpivbUSHBF7H.pgp
Description: PGP signature


Re: [tryton] About external module and README

2012-07-19 Thread Craig Barnes
On 19 July 2012 21:43, Cédric Krier cedric.kr...@b2ck.com wrote:
 On 19/07/12 22:31 +0200, Sergi Almacellas Abellana wrote:
 Al 19/07/12 22:24, En/na Cédric Krier ha escrit:
 On 19/07/12 22:03 +0200, Sergi Almacellas Abellana wrote:
 Why we don't add tryton.org (or the tryton foundation) in Package
 Index Owner and Package Index Maintainer to denote an official
 module? The rest of the modules will have it's own maintainer
 denoting that it isn't an official module.
 
 It makes sense to me. What do you think?
 Because it doesn't prevent name collision.
 Your solution only prevents name collision on the official modules.
 The collision will exists always in unofficial modules.

 Except if unofficial also follow a schema.
 I think B2CK will publish his packages under the prefix b2ck_ because
 it is the name of the project from where it comes.

 Let's take an example, if anyone create a package named trytond_hr,
 there are a lot of chances that one day or an other Tryton will have a
 module with the same name.
 We must see the trytond_ as a name space and this name space is
 devoted to Tryton.
 To tryton or to tryton related packages? IMHO makes more sense to
 tryton related packages.

 When I say Tryton I mean the project/community.

 By the way having let say a package named b2ck_hr doesn't prevent it to
 install a module named hr.
 
 By the way, I did not yet see any good explaination why non-Tryton
 packages should be prefixed by trytond_ ?
 And I did not yet see any good explanation why Tryton packages
 should not be prefixed by trytond_?

 - It brings confusion
 - It will create name collision:
   We can expect in the long term that there will be more
   unofficial packages than official. So each time a new
   official package will be created, its name will part of a long
   process to find a free name (which could be not the more accurate
   one).

 Finally, I would like to remember that if people wants to have a module
 be part of the official modules. He should join the community and
 follow the standard process:

 - blueprint
 - talks/mailing list
 - codereview…

 Otherwise, it could be feel as a hijacking of the project/community.

Maybe we should adopt a convention for community pipy package names i.e.

trytond_community_packagename

I don't believe we can reserve prefixes in pypi so we cant stop those
that would choose to hijack the name AFAIK.

I think a bigger problem will be the module name collisions at
installation, if there is an official trytond_party_bank and a
joebloggs_bank and both install modules/party_bank, what will the
result be when both are installed?

Neither neso or proteus are listed in Framework :: Tryton is this expected?

pip search tryton and regular web search for tryton finds those with
tryton in the description, so as long as it is in the description it
can be found with a trivial and web pip search.

-- 
Craig

'The first time any man's freedom is trodden on - we are all damaged.'
Jean-Luc Picard
()  ascii ribbon campaign - against html mail
/\

-- 
-- 
tryton@googlegroups.com mailing list





Re: [tryton] About external module and README

2012-07-19 Thread Cédric Krier
On 19/07/12 22:03 +0100, Craig Barnes wrote:
 Maybe we should adopt a convention for community pipy package names i.e.
 
 trytond_community_packagename

I find trytond_community also confusing because Tryton is a community.

 I don't believe we can reserve prefixes in pypi so we cant stop those
 that would choose to hijack the name AFAIK.

Yeps but we could point them as not fair people :-)

 I think a bigger problem will be the module name collisions at
 installation, if there is an official trytond_party_bank and a
 joebloggs_bank and both install modules/party_bank, what will the
 result be when both are installed?

We could expect pip to prevent collisions but from what I find on it it
doesn't seem to manage it. (Could be a good improvement)

 Neither neso or proteus are listed in Framework :: Tryton is this expected?

It seems to be a forget. Patch is welcome.

-- 
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric.kr...@b2ck.com
Website: http://www.b2ck.com/


pgpM1rnNIOV0H.pgp
Description: PGP signature


Re: [tryton] About external module and README

2012-07-18 Thread Cédric Krier
On 18/07/12 08:24 +0530, Sharoon Thomas wrote:
 On Jul 18, 2012, at 4:07 AM, Cédric Krier wrote:
 
  And finaly as we have a Tryton classifier, it will be great to not
  prefix those modules with trytond_ which also could confuse people.
 
 
 Other recommendations are fine, but these modules may still need to use 
 'trytond_' as a prefix so that python packaging will install the dependencies
 consistently (Example [1]). I think its good to keep the same convention 
 unless, we decide to complicate __tryton__ metadata with separate 
 standard addons and custom addons which changes the prefix accordingly,
 or removes it completely.

You are free to write your own setup.py.

-- 
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric.kr...@b2ck.com
Website: http://www.b2ck.com/


pgpdFRw2W2sfR.pgp
Description: PGP signature


Re: [tryton] About external module and README

2012-07-18 Thread Cédric Krier
On 18/07/12 17:02 +0200, Raimon Esteve wrote:
 2012/7/18 Cédric Krier cedric.kr...@b2ck.com:
  And finaly as we have a Tryton classifier, it will be great to not
  prefix those modules with trytond_ which also could confuse people.
 
 We like trytond prefix because all tryton server modules are group same 
 prefix.
 For example, Django modules/app add django prefix.
 
 With trytond prefix, group all modules from tryton server (visual list dir)

Ok but I think we will have trouble in the future because we will have
names collision. Or we could ask to put a prefix/suffix.

-- 
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric.kr...@b2ck.com
Website: http://www.b2ck.com/


pgp5HxiyDbY0z.pgp
Description: PGP signature


Re: [tryton] About external module and README

2012-07-18 Thread Raimon Esteve
 Ok but I think we will have trouble in the future because we will have
 names collision.

IMHO, I don't like company prefix same as openerp modules :(

pip install is available no-dependencies option.

Raimon

-- 
-- 
tryton@googlegroups.com mailing list





Re: [tryton] About external module and README

2012-07-18 Thread Raimon Esteve
2012/7/18 Raimon Esteve raimonest...@gmail.com:
 Ok but I think we will have trouble in the future because we will have
 names collision.

Last TUL, we talk about list modules availables (not only from
tryton.org). I don't talk  about app repository, if not wiki or
similar (documentation).
This place are available description module, where you do download,
dependencies and comments another people (who install it,
requeriments).

-- 
Si us plau, NO adjunti arxius a les seves respostes. Li preguem que
integri el text al cos del missatge. Pot respondre usant NetEtiquete
que li ajudarà a seguir la conversa.
http://es.wikipedia.org/wiki/Netiquette

Por favor, NO adjunte archivos a sus respuestas. Le rogamos que
integre el texto en el cuerpo del mensaje. Puede responder usando
NetEtiquete que le ayudará a seguir la
conversación.http://es.wikipedia.org/wiki/Netiquette

Please, DO NOT send attachment files with your answers, just copy and
paste only the text you need to send into the body of your mails.
Repply using NetEtiquete. http://en.wikipedia.org/wiki/Netiquette

-- 
-- 
tryton@googlegroups.com mailing list





Re: [tryton] About external module and README

2012-07-18 Thread Cédric Krier
On 18/07/12 17:23 +0200, Raimon Esteve wrote:
 2012/7/18 Raimon Esteve raimonest...@gmail.com:
  Ok but I think we will have trouble in the future because we will have
  names collision.
 
 Last TUL, we talk about list modules availables (not only from
 tryton.org). I don't talk  about app repository, if not wiki or
 similar (documentation).
 This place are available description module, where you do download,
 dependencies and comments another people (who install it,
 requeriments).

It is http://pypi.python.org/pypi?:action=browseshow=allc=551
But it could be improved with something like https://crate.io/

-- 
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric.kr...@b2ck.com
Website: http://www.b2ck.com/


pgpTGjsw1niH1.pgp
Description: PGP signature


[tryton] About external module and README

2012-07-17 Thread Cédric Krier
Hi,

We see  more and more third party modules, it is great for Tryton but I
see often that developpers just copy/paste the README file which could
bring some missunderstanding because it asks to report issues to the bug
tracker of Tryton. Also in the code, developpers just reused the
copyright notice This file is part of Tryton.

So Please try to not confuse people and update those files.

And finaly as we have a Tryton classifier, it will be great to not
prefix those modules with trytond_ which also could confuse people.

Thanks,
-- 
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric.kr...@b2ck.com
Website: http://www.b2ck.com/


pgp5NBK1rfmTM.pgp
Description: PGP signature


Re: [tryton] About external module and README

2012-07-17 Thread Sharoon Thomas
On Jul 18, 2012, at 4:07 AM, Cédric Krier wrote:

 And finaly as we have a Tryton classifier, it will be great to not
 prefix those modules with trytond_ which also could confuse people.


Other recommendations are fine, but these modules may still need to use 
'trytond_' as a prefix so that python packaging will install the dependencies
consistently (Example [1]). I think its good to keep the same convention 
unless, we decide to complicate __tryton__ metadata with separate 
standard addons and custom addons which changes the prefix accordingly,
or removes it completely.


[1] http://hg.tryton.org/2.4/modules/sale/file/7e68db93bc88/setup.py#l16

Thanks,

Sharoon Thomas
Openlabs Technologies  Consulting (P) Limited

w: http://www.openlabs.co.in
m: +1 813.793.6736 (OPEN) Extn. 200
t: @sharoonthomas 

- We CARE for our customers

-- 
-- 
tryton@googlegroups.com mailing list