Re: Inconsistency in source package naming for python modules
Thomas Goirand wrote: > On 07/11/2013 09:07 PM, Stuart Prescott wrote: >> >>> Oh, I need this pyX package... Let's download it. >> >> You're using a python module name because you need to import it. If you >> want to import modules, you want the binary package name; if you want to >> work on the source package then you need *either* the binary package name >> or the source package name as others have already pointed out. Knowledge >> of source package names isn't required. > > But if you have py (let's say on pypi), then even the binary > package isn't obvious. It could be: > python-py > > or: > python- > > I've seen both cases in the archive! and changing source package names isn't going to solve that either. There is no convention in python-land to only have one top-level module name per project in the namespace and to name your project after that top-level module. At that point, the unification of namespaces between pypi (or any of the other multitude of module repositories), source packages and binary packages becomes impossible. As Paul indicated, this is a difficult problem with a different solution. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/krmtme$tun$1...@ger.gmane.org
Re: Inconsistency in source package naming for python modules
On Fri, Jul 12, 2013 at 12:22 AM, Thomas Goirand wrote: > I've seen both cases in the archive! DEP-11 FTW. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6E-E-8f0ue1h6cRu3PkEw3mj=ctJmNM5duCeDXgD=8...@mail.gmail.com
Re: Inconsistency in source package naming for python modules
On 07/11/2013 09:07 PM, Stuart Prescott wrote: > >> Oh, I need this pyX package... Let's download it. > > You're using a python module name because you need to import it. If you want > to import modules, you want the binary package name; if you want to work on > the source package then you need *either* the binary package name or the > source package name as others have already pointed out. Knowledge of source > package names isn't required. But if you have py (let's say on pypi), then even the binary package isn't obvious. It could be: python-py or: python- I've seen both cases in the archive! Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51dedbc9.7000...@debian.org
Re: Inconsistency in source package naming for python modules
> Oh, I need this pyX package... Let's download it. You're using a python module name because you need to import it. If you want to import modules, you want the binary package name; if you want to work on the source package then you need *either* the binary package name or the source package name as others have already pointed out. Knowledge of source package names isn't required. (I'll assume that your X in pyX was a placeholder... given that there is actually a pyx source package and a python-pyx binary package and debian package names are downcased, it's actually a rather confusing example to pick... using a policy-compliant lower case name "apt-get source pyx" or "apt-get source python-pyx" both work just fine.) Binary package names for module packages already follow the python policy of being python-foo where you want to "import foo". The thing that we do not easily get from this is the case when we "import foo.bar" and we need to work out if that's in the "python-foo" package or perhaps in a "python- foo.bar" package. At present we have apt-file or dpkg -S to deal with this problem and in the future, as noted by Paul, DEP11 will give us a way of discovering this information much more easily (and this a common problem for perl and java and …). This module discovery is orthogonal to source package naming; note that exactly the same problem exists in trying to work out if foo and foo.bar were the same or different source packages no matter what naming scheme you want to come up with. If your py$X in your example is not in a binary package called python-py$X and it is a public module-only package then it's already not policy compliant and wants fixing. Report a bug about the binary package name. Cite the appropriate part of python policy in it. If the module is in a policy- compliant binary package then your problem is already solved as has been already pointed out so there's nothing to fix here. Knowledge of the source package name was not required. Also note that your example of trying to find source package names by divination is still not going to work problem where a python module is provided as bindings its own C library. There are many sources like these -- let's look at one such example: xapian-bindings Package-List: libxapian-ruby1.8 deb ruby optional libxapian-ruby1.9.1 deb ruby optional python-xapian deb python optional tclxapian deb libs optional So that source package should be renamed to python-xapian because the python people want unified source package naming? Clearly not. And once you know you have a pile of exceptions to whatever naming scheme you want, it's not a useful naming scheme -- you'll be back to either (a) stumbling around trying things at random as per your examples or (b) using the tools we have that accept either binary or source package names or (c) using the available tools to look up the correct information to feed to git svn. > And that's just an example on what can go wrong and be really annoying. > It's even more annoying when you are trying to do a "git svn clone" > which takes forever. If you want to get the VCS data for the python-foo binary package: $ apt-cache showsrc python-foo | grep Vcs Knowledge of the source package name was not required. Like the other apt- get commands shown by others, apt-cache showsrc takes binary package names as well as source package names. I guess it will take less than forever to write the appropriate 2 line shell script to solve this problem for you as your own replacement to the existing debcheckout. (Or perhaps you'd like to add a couple of lines to debcheckout to offer git-svn there? line 526 looks like the right place for you to start -- debcheckout is in the devscripts package for submitting patches to the bts.) Making use of existing tools and extending them where necessary so that they always work seems a lot more useful than creating some sort of flawed naming scheme that will only ever sometimes work. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/krmamp$p1j$1...@ger.gmane.org
Re: Inconsistency in source package naming for python modules
On 07/11/2013 04:07 AM, Piotr Ożarowski wrote: > [Thomas Goirand, 2013-07-10] >> And then, finally, it's called "migrate" instead of "sqlalchemy-migrate" >> like upstream called it... :) >> (this never happened to me with python-migrate, though that's a good >> example of a IMO badly named source package) > > if you wanted to download python-migrate's sources... why didn't you > tell apt-get that that's what you want? > apt-get is clever enough to figure out the right source package name: > > $ apt-get source python-migrate > [...] > Picking 'migrate' as source package instead of 'python-migrate' > [...] Please don't pick on that specific example. > `debcheckout python-migrate` will pick the right source package as well debcheckout will use SVN, and I prefer git-svn. Anyway, we're digressing. If you don't see a value in consistency, never mind. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51de57b2.5000...@debian.org
Re: Inconsistency in source package naming for python modules
On 07/11/2013 03:59 AM, Bradley M. Froehle wrote: > I think a recommendation (for new packages) would be helpful, but I'm > against any source naming requirements or strict rules. Then we agree! That's all what I'm asking for. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51de573e.9060...@debian.org
Re: Inconsistency in source package naming for python modules
On Thu, Jul 11, 2013 at 3:54 AM, Thomas Goirand wrote: > Oh, I need this pyX package... Let's download it. I assume here you mean "I need whatever package provides 'import pyX' for python"? If so this is solvable using something like DEP-11 that maps package names to things that they provide (shared libs, manpages, python modules, fonts, glyph ranges, info pages, hardware support, applications etc). The idea isn't yet finalised or implemented but there is some info here: http://wiki.debian.org/DEP-11 I imagine the way it will work is something like this: apt-get install component:python:pyx -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6HL9TRaL9Y1Zsu4=kg9ottzmvw0nwvmyhbs_+uotmt...@mail.gmail.com
Re: Inconsistency in source package naming for python modules
On Jul 11, 2013, at 03:54 AM, Thomas Goirand wrote: >Ok, so let's not use the word "rule" but call it "guide-line", and for >future packages only (I have *never* proposed to change already uploaded >packages). Do you feel more comfortable now? :) Does your response mean you disagree with my suggested recommendation? Also, did you see the code I posted a link to previously? $ python wid.py -u debian configglue import path: /usr/lib/python2.7/dist-packages/configglue/__init__.py Binary/source in Debian: python-configglue python-configglue | 1.0-1 | wheezy | source, all python-configglue | 1.0-1 | jessie | source, all python-configglue | 1.0-1 | sid| source, all $ python3 wid.py -u debian flufl.enum import path: /usr/lib/python3/dist-packages/flufl/enum/__init__.py Binary in Debian: python3-flufl.enum python3-flufl.enum | 3.3.2-1 | wheezy | all python3-flufl.enum | 3.3.2-1 | jessie | all python3-flufl.enum | 3.3.2-1 | sid| all Source in Debian: flufl.enum flufl.enum | 3.3.2-1 | wheezy | source flufl.enum | 3.3.2-1 | jessie | source flufl.enum | 3.3.2-1 | sid| source Of course, the one limitation is that the package has to be already installed and importable. -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130710171335.410cf762@anarchist
Re: Inconsistency in source package naming for python modules
[Thomas Goirand, 2013-07-10] > And then, finally, it's called "migrate" instead of "sqlalchemy-migrate" > like upstream called it... :) > (this never happened to me with python-migrate, though that's a good > example of a IMO badly named source package) if you wanted to download python-migrate's sources... why didn't you tell apt-get that that's what you want? apt-get is clever enough to figure out the right source package name: $ apt-get source python-migrate [...] Picking 'migrate' as source package instead of 'python-migrate' [...] > And that's just an example on what can go wrong and be really annoying. > It's even more annoying when you are trying to do a "git svn clone" > which takes forever. `debcheckout python-migrate` will pick the right source package as well -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130710200741.gb9...@p1otr.com
Re: Inconsistency in source package naming for python modules
On Wed, Jul 10, 2013 at 12:54 PM, Thomas Goirand wrote: > On 07/10/2013 10:30 PM, Stuart Prescott wrote: >> Thomas Goirand wrote: >>> On 07/08/2013 10:10 PM, Scott Kitterman wrote: There is no policy on this either way, so there's no "mistake". >>> >>> Well, the mistake is precisely to have no rule, IMO. >> >> Rules for packaging things are normally there to solve problems of >> interoperability and to assist QA efforts. Which of these is it going to >> help? >> >>> Never the less, I think we should collectively decide what to do, rather >>> than continuing the mess, with everyone having its own rule. >> >> What mess? If there is a perceived mess, why is that a problem in any case? >> How does it help to make a new rule? Who does it help? What problem does >> this solve? Why is any intellectual energy being spent on this at all? > > Oh, I need this pyX package... Let's download it. > > # apt-get source pyX > Reading package lists... Done > Building dependency tree > Reading state information... Done > E: Unable to find a source package for pyX > > shit, let's try again... It works to me (in Ubuntu, anyway): $ apt-get source python-matplotlib Reading package lists... Done Building dependency tree Reading state information... Done Picking 'matplotlib' as source package instead of 'python-matplotlib' NOTICE: 'matplotlib' packaging is maintained in the 'Svn' version control system at: svn://svn.debian.org/svn/python-modules/packages/matplotlib/trunk/ Need to get 38.5 MB of source archives. Get:1 http://mirror.pnl.gov/ubuntu/ raring/universe matplotlib 1.2.1-0ubuntu1 (dsc) [3,240 B] Get:2 http://mirror.pnl.gov/ubuntu/ raring/universe matplotlib 1.2.1-0ubuntu1 (tar) [38.4 MB] Get:3 http://mirror.pnl.gov/ubuntu/ raring/universe matplotlib 1.2.1-0ubuntu1 (diff) [25.1 kB] I think a recommendation (for new packages) would be helpful, but I'm against any source naming requirements or strict rules. -Brad -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cahxv-mgtoi_l8v6jjdrty3skdpenb7yh1d_pv6uvcvgqwxj...@mail.gmail.com
Re: Inconsistency in source package naming for python modules
On 07/10/2013 10:30 PM, Stuart Prescott wrote: > Thomas Goirand wrote: >> On 07/08/2013 10:10 PM, Scott Kitterman wrote: >>> There is no policy on this either way, so there's no "mistake". >> >> Well, the mistake is precisely to have no rule, IMO. > > Rules for packaging things are normally there to solve problems of > interoperability and to assist QA efforts. Which of these is it going to > help? > >> Never the less, I think we should collectively decide what to do, rather >> than continuing the mess, with everyone having its own rule. > > What mess? If there is a perceived mess, why is that a problem in any case? > How does it help to make a new rule? Who does it help? What problem does > this solve? Why is any intellectual energy being spent on this at all? Oh, I need this pyX package... Let's download it. # apt-get source pyX Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to find a source package for pyX shit, let's try again... # apt-get source python-X Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to find a source package for python-X grr... # apt-get source X Reading package lists... Done Building dependency tree Reading state information... Done [...] And then, finally, it's called "migrate" instead of "sqlalchemy-migrate" like upstream called it... :) (this never happened to me with python-migrate, though that's a good example of a IMO badly named source package) And that's just an example on what can go wrong and be really annoying. It's even more annoying when you are trying to do a "git svn clone" which takes forever. Sure, we can continue and have a "free for all" thing, though knowing what the others do, and try to do the same so we *at least try* to have a bit of consistency, can't hurt. > It looks exceedingly like a rule for the sake of having a rule. It will be > an exceedingly complicated rule in that it will have to cover python > modules, python applications and other libraries that offer python bindings > all separately. It will have to be accompanied an explanation of why so many > packages don't follow it because they were uploaded prior to the rule > existing. Basically... unless we are going to force every existing source > package to change name to comply with this rule there is no point in having > it (and no-one has advocated renaming source packages as is useless work for > everyone). Ok, so let's not use the word "rule" but call it "guide-line", and for future packages only (I have *never* proposed to change already uploaded packages). Do you feel more comfortable now? :) Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ddbbdb.6070...@debian.org
Re: Inconsistency in source package naming for python modules
Am 10.07.2013 16:30, schrieb Stuart Prescott: > Thomas Goirand wrote: >> On 07/08/2013 10:10 PM, Scott Kitterman wrote: >>> There is no policy on this either way, so there's no "mistake". >> >> Well, the mistake is precisely to have no rule, IMO. > > Rules for packaging things are normally there to solve problems of > interoperability and to assist QA efforts. Which of these is it going to > help? > >> Never the less, I think we should collectively decide what to do, rather >> than continuing the mess, with everyone having its own rule. > > What mess? If there is a perceived mess, why is that a problem in any case? > How does it help to make a new rule? Who does it help? What problem does > this solve? Why is any intellectual energy being spent on this at all? energy? maybe. but intellectual? > It looks exceedingly like a rule for the sake of having a rule. It will be > an exceedingly complicated rule in that it will have to cover python > modules, python applications and other libraries that offer python bindings > all separately. It will have to be accompanied an explanation of why so many > packages don't follow it because they were uploaded prior to the rule > existing. Basically... unless we are going to force every existing source > package to change name to comply with this rule there is no point in having > it (and no-one has advocated renaming source packages as is useless work for > everyone). It is good to have a naming schema for binary packages, however it is easy to get from there to the name of the source package. I think I got some bug reports to include the upstream source name into the short package description when it doesn't match the module name, so that it can be found by apt-cache -n search. But again, no need for a policy here. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51dd84a6.8020...@debian.org
Re: Inconsistency in source package naming for python modules
[Stuart Prescott, 2013-07-10] > What mess? If there is a perceived mess, why is that a problem in any case? > How does it help to make a new rule? Who does it help? What problem does > this solve? Why is any intellectual energy being spent on this at all? > > It looks exceedingly like a rule for the sake of having a rule. It will be > an exceedingly complicated rule in that it will have to cover python > modules, python applications and other libraries that offer python bindings > all separately. It will have to be accompanied an explanation of why so many > packages don't follow it because they were uploaded prior to the rule > existing. Basically... unless we are going to force every existing source > package to change name to comply with this rule there is no point in having > it (and no-one has advocated renaming source packages as is useless work for > everyone). > > Rules like this look like yet another small barrier to entry to new > contributors in the form of yet another thing to learn. Debian already has > too many administrative hurdles and piles of little rules that scare away > people. I'm yet to understand whether rules like this are created for > benefit of people who like to have a policy with which to berate others or > by people who like to impose order on the world around them. > > 2¢ +1 -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130710144147.ga9...@p1otr.com
Re: Inconsistency in source package naming for python modules
On Thursday, July 11, 2013 12:30:54 AM Stuart Prescott wrote: > Thomas Goirand wrote: > > On 07/08/2013 10:10 PM, Scott Kitterman wrote: > >> There is no policy on this either way, so there's no "mistake". > > > > Well, the mistake is precisely to have no rule, IMO. > > Rules for packaging things are normally there to solve problems of > interoperability and to assist QA efforts. Which of these is it going to > help? > > > Never the less, I think we should collectively decide what to do, rather > > than continuing the mess, with everyone having its own rule. > > What mess? If there is a perceived mess, why is that a problem in any case? > How does it help to make a new rule? Who does it help? What problem does > this solve? Why is any intellectual energy being spent on this at all? > > It looks exceedingly like a rule for the sake of having a rule. It will be > an exceedingly complicated rule in that it will have to cover python > modules, python applications and other libraries that offer python bindings > all separately. It will have to be accompanied an explanation of why so many > packages don't follow it because they were uploaded prior to the rule > existing. Basically... unless we are going to force every existing source > package to change name to comply with this rule there is no point in having > it (and no-one has advocated renaming source packages as is useless work > for everyone). > > Rules like this look like yet another small barrier to entry to new > contributors in the form of yet another thing to learn. Debian already has > too many administrative hurdles and piles of little rules that scare away > people. I'm yet to understand whether rules like this are created for > benefit of people who like to have a policy with which to berate others or > by people who like to impose order on the world around them. > > 2¢ +100 Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/6053284.UBF8s8i61a@scott-latitude-e6320
Re: Inconsistency in source package naming for python modules
Thomas Goirand wrote: > On 07/08/2013 10:10 PM, Scott Kitterman wrote: >> There is no policy on this either way, so there's no "mistake". > > Well, the mistake is precisely to have no rule, IMO. Rules for packaging things are normally there to solve problems of interoperability and to assist QA efforts. Which of these is it going to help? > Never the less, I think we should collectively decide what to do, rather > than continuing the mess, with everyone having its own rule. What mess? If there is a perceived mess, why is that a problem in any case? How does it help to make a new rule? Who does it help? What problem does this solve? Why is any intellectual energy being spent on this at all? It looks exceedingly like a rule for the sake of having a rule. It will be an exceedingly complicated rule in that it will have to cover python modules, python applications and other libraries that offer python bindings all separately. It will have to be accompanied an explanation of why so many packages don't follow it because they were uploaded prior to the rule existing. Basically... unless we are going to force every existing source package to change name to comply with this rule there is no point in having it (and no-one has advocated renaming source packages as is useless work for everyone). Rules like this look like yet another small barrier to entry to new contributors in the form of yet another thing to learn. Debian already has too many administrative hurdles and piles of little rules that scare away people. I'm yet to understand whether rules like this are created for benefit of people who like to have a policy with which to berate others or by people who like to impose order on the world around them. 2¢ Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/krjr6p$kmq$1...@ger.gmane.org
Re: Inconsistency in source package naming for python modules
On Jul 10, 2013, at 08:11 AM, Alastair McKinstry wrote: >FWIW, I think the current scheme works best. > >I manage a bunch of packages that have python wrappers; the package >then pretty much _has_ to follow the current scheme, eg. > >Source package: silo >Bin packages: libsilo0 >libsilo-dev >python-silo >python3-silo (coming). This seems completely reasonable to me. -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130710090636.063a727b@anarchist
Re: Inconsistency in source package naming for python modules
On Jul 10, 2013, at 02:58 PM, Thomas Goirand wrote: >On 07/08/2013 10:10 PM, Scott Kitterman wrote: >> There is no policy on this either way, so there's no "mistake". > >Well, the mistake is precisely to have no rule, IMO. > >On 07/08/2013 11:37 PM, Barry Warsaw wrote: >> Hopefully, it will become more and more common to have at least >> python-X and python3-X. With that in mind, many of our source >> packages that are producing a single binary package today should >> hopefully be producing two or more binary packages tomorrow. > >Never the less, I think we should collectively decide what to do, rather >than continuing the mess, with everyone having its own rule. While I'm in favor of more consistency, I'm not sure it will be possible to come up with a hard and fast rule. As for consistency, the discussion here should help and we can promote recommendations in our wiki/docs and when we review packages. As I've stated, my own personal preference is to name the source package after the PyPI name (which usually means without the `python-` prefix) unless there are extenuating circumstances, e.g. collisions or confusions with other packages. We already have rules for naming the binary packages. -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130710090539.46a0eb12@anarchist
Re: Inconsistency in source package naming for python modules
FWIW, I think the current scheme works best. I manage a bunch of packages that have python wrappers; the package then pretty much _has_ to follow the current scheme, eg. Source package: silo Bin packages: libsilo0 libsilo-dev python-silo python3-silo (coming). A policy on renaming the source package isn't likely to change silo, etc. and so a greater inconsistency follows. regards Alastair On 10/07/2013 07:58, Thomas Goirand wrote: > On 07/08/2013 10:10 PM, Scott Kitterman wrote: >> There is no policy on this either way, so there's no "mistake". > Well, the mistake is precisely to have no rule, IMO. > > On 07/08/2013 11:37 PM, Barry Warsaw wrote: >> Hopefully, it will become more and more common to have at least >> python-X and python3-X. With that in mind, many of our source >> packages that are producing a single binary package today should >> hopefully be producing two or more binary packages tomorrow. > Never the less, I think we should collectively decide what to do, rather > than continuing the mess, with everyone having its own rule. > > Thomas > > -- Alastair McKinstry , , http://blog.sceal.ie Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51dd0912.30...@sceal.ie
Re: Inconsistency in source package naming for python modules
On Wed, Jul 10, 2013 at 8:58 AM, Thomas Goirand wrote: > On 07/08/2013 10:10 PM, Scott Kitterman wrote: >> There is no policy on this either way, so there's no "mistake". > > Well, the mistake is precisely to have no rule, IMO. Agreed. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAA77j2B=8ZYV3XjkJmTX5-UG1Vi3m4rmSXOLi4zmtithB5d4=g...@mail.gmail.com
Re: Inconsistency in source package naming for python modules
On 07/08/2013 10:10 PM, Scott Kitterman wrote: > There is no policy on this either way, so there's no "mistake". Well, the mistake is precisely to have no rule, IMO. On 07/08/2013 11:37 PM, Barry Warsaw wrote: > Hopefully, it will become more and more common to have at least > python-X and python3-X. With that in mind, many of our source > packages that are producing a single binary package today should > hopefully be producing two or more binary packages tomorrow. Never the less, I think we should collectively decide what to do, rather than continuing the mess, with everyone having its own rule. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51dd0631.5000...@debian.org
Re: Inconsistency in source package naming for python modules
Another rule of thumb I use is that if a project is not just about python module but also provides some GUI or CUI interface which might be used by users without realizing presence of a python behind I do not prefix with python-, eg psychopy. Sandro Tosi wrote: >On Mon, Jul 8, 2013 at 4:10 PM, Scott Kitterman >wrote: >> There is no policy on this either way, so there's no "mistake". >Personally, I >> tend to use the upstream name for the source package name and >> python-$modulename (per Python policy) for the binary. > >I'm using the same same rule, with just one exception: I'm calling >source package python-X if X is too generic (see python-psutil, where >upstream is calling the project psutil, too close to psutils). I don't >feel there's anything to "fix" here, or to write a policy for source >package name. > >Regards, >-- >Sandro Tosi (aka morph, morpheus, matrixhasu) >My website: http://matrixhasu.altervista.org/ >Me at Debian: http://wiki.debian.org/SandroTosi -- Sent from a phone which beats iPhone. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/89e4a6bb-fc21-4c30-a1d7-b08808406...@email.android.com
Re: Inconsistency in source package naming for python modules
On Mon, Jul 8, 2013 at 4:10 PM, Scott Kitterman wrote: > There is no policy on this either way, so there's no "mistake". Personally, I > tend to use the upstream name for the source package name and > python-$modulename (per Python policy) for the binary. I'm using the same same rule, with just one exception: I'm calling source package python-X if X is too generic (see python-psutil, where upstream is calling the project psutil, too close to psutils). I don't feel there's anything to "fix" here, or to write a policy for source package name. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cab4xwxwkkbo23b4nlgvnqxctsfoeprnqztuqgggmkrwj9qv...@mail.gmail.com
Re: Inconsistency in source package naming for python modules
On Jul 08, 2013, at 09:59 PM, Thomas Goirand wrote: >Over the last months, I've seen lots of inconsistency in the source >package naming scheme in the python module maintained in the team. >Sometimes, module X will have its source package called python-X or just X. > >If we have a python module named X, then IMO, we should stick to call >the source package python-X, and not just X. Why? Because AFAICT it >seems that there's a consensus in Debian that, if a package is producing >a single binary, then its source package should have the same name. Hopefully, it will become more and more common to have at least python-X and python3-X. With that in mind, many of our source packages that are producing a single binary package today should hopefully be producing two or more binary packages tomorrow. >It isn't my intention to fix mistakes already made (IMO, too much work >for not enough rewards), but I wanted to raise this topic to check if >others have the same opinion, and to make sure we have this in the >python policy (in one way or the other). Thoughts anyone? In light of the above, I think it makes sense to name the source package after the upstream package name if possible, e.g. as you might see it on PyPI. Of course, there's a wild variation there too[1]. But I think that makes it generally easier to find the path back to the original source[2]. -Barry [1] e.g. mimeparse and python-mimeparse look quite similar except the latter works in Python 3 instead of just claiming to. ;) [2] Here's a dumb little script I've always wanted. http://bazaar.launchpad.net/~barry/+junk/wid/view/head:/wid.py -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130708113716.2cc387cd@anarchist
Re: Inconsistency in source package naming for python modules
Quoting Thomas Goirand (2013-07-08 15:59:02) > Hi, > > Over the last months, I've seen lots of inconsistency in the source > package naming scheme in the python module maintained in the team. > Sometimes, module X will have its source package called python-X or just X. > > If we have a python module named X, then IMO, we should stick to call > the source package python-X, and not just X. Why? Because AFAICT it > seems that there's a consensus in Debian that, if a package is producing > a single binary, then its source package should have the same name. I can find at least one source that prones something different: [1] http://www.debian.org/doc/manuals/maint-guide/first.en.html#namever Cheers, Simon signature.asc Description: signature
Re: Inconsistency in source package naming for python modules
On Monday, July 08, 2013 09:59:02 PM Thomas Goirand wrote: > Hi, > > Over the last months, I've seen lots of inconsistency in the source > package naming scheme in the python module maintained in the team. > Sometimes, module X will have its source package called python-X or just X. > > If we have a python module named X, then IMO, we should stick to call > the source package python-X, and not just X. Why? Because AFAICT it > seems that there's a consensus in Debian that, if a package is producing > a single binary, then its source package should have the same name. > > It isn't my intention to fix mistakes already made (IMO, too much work > for not enough rewards), but I wanted to raise this topic to check if > others have the same opinion, and to make sure we have this in the > python policy (in one way or the other). Thoughts anyone? There is no policy on this either way, so there's no "mistake". Personally, I tend to use the upstream name for the source package name and python-$modulename (per Python policy) for the binary. I think this is quite reasonable and would be against anything that made it somehow wrong. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7346611.zpGeSbo3K4@scott-latitude-e6320
Inconsistency in source package naming for python modules
Hi, Over the last months, I've seen lots of inconsistency in the source package naming scheme in the python module maintained in the team. Sometimes, module X will have its source package called python-X or just X. If we have a python module named X, then IMO, we should stick to call the source package python-X, and not just X. Why? Because AFAICT it seems that there's a consensus in Debian that, if a package is producing a single binary, then its source package should have the same name. It isn't my intention to fix mistakes already made (IMO, too much work for not enough rewards), but I wanted to raise this topic to check if others have the same opinion, and to make sure we have this in the python policy (in one way or the other). Thoughts anyone? Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51dac5a6.5090...@debian.org
