Re: python / python3 3 pybuild and bin script

2014-02-05 Thread Thomas Goirand
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

2014-02-05 Thread picca
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

2014-02-05 Thread Ben Finney
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

2014-02-05 Thread picca
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