[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <picca@synchrotron-soleil.fr>

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 <picca@debian.org>


Reply to: