Re: python / python3 3 pybuild and bin script
On 02/01/2014 04:10 PM, PICCA Frederic-Emmanuel wrote: > Hello, > > I am packaging the next version of spyder which is a python IDE. > The next version will support python3 > > so I need to add a spyder3 binary package which will contain > /usr/bin/spyder3 > > the upstream script only create /usr/bin/spyder during the build > > So my question is do we have something in pybuild which help to rename a > script > and add 3 at the end of the official script. > > If not can you explain in the wiki how to proceed in thaht case > > It is quite usuall to add a 3 at the end of the scripts for python3 version. Hi, Thanks for raising this important topic. What I've been doing up to now, is renaming "foo" into "python3-foo" and "python2-foo", then I use update-alternatives to provide /usr/bin/foo, with the python2 version having the priority. Sometimes I've even used "foo-python3" and "foo-python2" (and I feel bad about my lack of consistency, though since we have no defined standards...). Though I'm seeing that you just add a "3" to the python3 version, which in some way works well too. Though do you also add a "2" for the python2 version? Do you use update-alternatives? Also, I've experienced that using update-alternatives the correct way is somehow counter-intuitive and badly documented (see: #71621). Thoughts anyone? What would you consider best practice? Cheers, 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/52f1f346.3090...@debian.org
Re: python / python3 3 pybuild and bin script
On Wed, Feb 05, 2014 at 04:16:06PM +0800, Thomas Goirand wrote: > Hi, Hello > > Thanks for raising this important topic. > > What I've been doing up to now, is renaming "foo" into "python3-foo" and > "python2-foo", then I use update-alternatives to provide /usr/bin/foo, > with the python2 version having the priority. Sometimes I've even used > "foo-python3" and "foo-python2" (and I feel bad about my lack of > consistency, though since we have no defined standards...). > Though I'm seeing that you just add a "3" to the python3 version, which > in some way works well too. Though do you also add a "2" for the python2 > version? Do you use update-alternatives? No I do not have a 2 for the current script. I think that I should have a spyder2.7 and a link to spyder -> spyder2.7 like python2.6 python2.7 and python I considere that spyder3 is not equivalent to spyder2 so I do not want to use the alternatives for this purpose. > > Also, I've experienced that using update-alternatives the correct way is > somehow counter-intuitive and badly documented (see: #71621). I never try to use this system since I am not very confortable with it. > > Thoughts anyone? What would you consider best practice? Yes opinions of other would be interesing. See you Fred -- GPG public key 4096R/4696E015 2011-02-14 fingerprint = E92E 7E6E 9E9D A6B1 AA31 39DC 5632 906F 4696 E015 uid Picca Frédéric-Emmanuel GPG public key 1024D/A59B1171 2009-08-11 fingerprint = 1688 A3D6 F0BD E4DF 2E6B 06AA B6A9 BA6A A59B 1171 uid Picca Frédéric-Emmanuel -- 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/20140205083104.ga21...@synchrotron-soleil.fr
Re: python / python3 3 pybuild and bin script
PICCA Frederic-Emmanuel writes: > I am packaging the next version of spyder which is a python IDE. Thanks for working to package useful software for Debian. > The next version will support python3 > so I need to add a spyder3 binary package which will contain > /usr/bin/spyder3 This implies (because you're naming the binary differently) that the new version will have features *incompatible* with previous versions. How so? Note that it doesn't matter what the program is implemented with; the binary should be named for what it *does* from an end-user perspective, not what it's built with. > the upstream script only create /usr/bin/spyder during the build Is that a problem? What would an end user care? Note that I'm not assuming an answer — perhaps there really is some important difference between the way the new version behaves that means a user will notice incompatibilities. But this isn't necessarily so just because of “support for Python 3”. > It is quite usuall to add a 3 at the end of the scripts for python3 > version. Maybe so, but often that is simply because of cargo-cult programming. If the programs implement effectively the same features, the programs can be named the same (and ‘update-alternatives’ would be a good choice for managing the different versions). If they do not – if the different versions implement different functionality such that the user will need to care about which one they invoke – then the programs should have different names (and ‘update-alternatives’ is *not* a good option, because this is contrary to its purpose). -- \ “Faith may be defined briefly as an illogical belief in the | `\ occurrence of the improbable.” —Henry L. Mencken | _o__) | Ben Finney -- 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/85ppn2dj0w@benfinney.id.au
Re: python / python3 3 pybuild and bin script
On Wed, Feb 05, 2014 at 08:07:59PM +1100, Ben Finney wrote: > > The next version will support python3 > > so I need to add a spyder3 binary package which will contain > > /usr/bin/spyder3 > > This implies (because you're naming the binary differently) that the new > version will have features *incompatible* with previous versions. How > so? not necessarely but since the version with python3 is brand new, there is more probablility of bugs. So for now the production code is the python2 version. spyder3 (python3) is a sort of python3 preview and need more polishing until we can considere it as stable as the current python2 version. The idea is to provide this python3 version in order to have more bug report and improve it. > > Note that it doesn't matter what the program is implemented with; the > binary should be named for what it *does* from an end-user perspective, > not what it's built with. I agree with you on this point, users should not care, but in thaht case they care because the spyder3 is more risky in term of bugs. > > > the upstream script only create /usr/bin/spyder during the build > > Is that a problem? What would an end user care? They should not at the end when poython3 version will be as stable asd the python2 version. > > Note that I'm not assuming an answer — perhaps there really is some > important difference between the way the new version behaves that means > a user will notice incompatibilities. But this isn't necessarily so just > because of “support for Python 3”. no this should be the same at the end. I speak here about a transition phase whihc should be quite long (python2 python3 transition ;) > > > It is quite usuall to add a 3 at the end of the scripts for python3 > > version. > > Maybe so, but often that is simply because of cargo-cult programming. If > the programs implement effectively the same features, the programs can > be named the same (and ‘update-alternatives’ would be a good choice for > managing the different versions). the big difference is that completion during code writing depends of the present of the package intalled on the system. So since not all packages where migrated to python3 there is difference when using python2 and python3 version :) > If they do not – if the different versions implement different > functionality such that the user will need to care about which one they > invoke – then the programs should have different names (and > ‘update-alternatives’ is *not* a good option, because this is contrary > to its purpose). I think so and this is why I propose to use spyder3 instead of spyder, to be clear that the stability is not of the same level for now. Cheers Frederic -- GPG public key 4096R/4696E015 2011-02-14 fingerprint = E92E 7E6E 9E9D A6B1 AA31 39DC 5632 906F 4696 E015 uid Picca Frédéric-Emmanuel GPG public key 1024D/A59B1171 2009-08-11 fingerprint = 1688 A3D6 F0BD E4DF 2E6B 06AA B6A9 BA6A A59B 1171 uid Picca Frédéric-Emmanuel -- 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/20140205092207.ga22...@synchrotron-soleil.fr