[Slackbuilds-users] six and python3-six

[B Watson]

Do we need separate six and python3-six builds?

Right now, six will build & install python3 support if python3 is
installed on the build box. python3-six is identical, except (a) it
requires python3 in the .info file and (b) it builds only the python3
stuff.

I'd say either these 2 builds should be combined, or else the six build
should be modified so it's python2-only (get rid of optional python3
support).

But, I'm not the maintainer of either of these, and I'm not even a
Python programmer.

Opinions?
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-***@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[B Watson]

Post by B Watson
Do we need separate six and python3-six builds?

Disregard previous email on this subject, I see that six has been updated
to only install python2 modules. I was looking at the slackonly binary
packages, not the latest SBo.

Apologies if I raised anyone's blood pressure.
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-***@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Rich Shepard]

Post by B Watson
Do we need separate six and python3-six builds?
Right now, six will build & install python3 support if python3 is
installed on the build box. python3-six is identical, except (a) it
requires python3 in the .info file and (b) it builds only the python3
stuff.

I'm a Python end-user and support the idea of having one build that
supports both Python2 and Python3. All my new code is Python3 but many
applications remain bound to Python2. It will take a while for everyone to
migrate to Python3.

Rich
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-***@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Benjamin Trigona-Harany]

Post by B Watson
Do we need separate six and python3-six builds?
Right now, six will build & install python3 support if python3 is
installed on the build box. python3-six is identical, except (a) it
requires python3 in the .info file and (b) it builds only the python3
stuff.

  I'm a Python end-user and support the idea of having one build that
supports both Python2 and Python3. All my new code is Python3 but many
applications remain bound to Python2. It will take a while for everyone to
migrate to Python3.

For what it's worth, when 15.0 is released, I strongly advocate that
Python SlackBuilds cover both Python 2 and 3 together in the same script
- just like Pat is doing on current now. Yes, there are few cases where
this won't be possible due to incompatibilities (for example IPython
needs different versions for Python 2 and Python 3), but those are
exceptions.

For 14.2, there are several approaches being taken depending on the
script maintainer, including various types of support for Python 3 in a
Python 2 build script or having two scripts, one each for 2 and 3. My
opinion is that we probably don't want to rock the boat too much during
14.2's lifetime but when we do switch to 15.0, I expect to see quite a
bit of change in the Python SlackBuilds landscape.

That being said, I have added *mandatory* Python 3 support to a few of
my SlackBuild scripts to gauge whether it might make sense to start the
conversion earlier (e.g.
https://git.slackbuilds.org/slackbuilds/commit/?id=1ffc4da77ce21b851bb6dbb8fe01638a8b8d411b).

So far no complaints. It's 2018 ... who still objects to having Python 3
installed?
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-***@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ

[Rich Shepard]

six is a special case, as it is provides compatibility for scripts running
different versions of python. It is useful to be able to create 2 separate
packages though, a python2 version, and a python3 version (with different
package names), because you can have both installed at the same time. It
would be hard to do that with only one package with options, unless the
options changed the package name - which would then make it harder to
manage with tools.

Tim,

Yes. I forgot that six is different from other python tools.

Regards,

Rich
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-***@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Heinz Wiesinger]

On Tuesday, 30 October 2018 17:55:59 CET Tim Dickson via SlackBuilds-users

Post by Rich Shepard

Post by B Watson
Do we need separate six and python3-six builds?
Right now, six will build & install python3 support if python3 is
installed on the build box. python3-six is identical, except (a) it
requires python3 in the .info file and (b) it builds only the python3
stuff.

I'm a Python end-user and support the idea of having one build that
supports both Python2 and Python3. All my new code is Python3 but many
applications remain bound to Python2. It will take a while for everyone to
migrate to Python3.
Rich
_______________________________________________
SlackBuilds-users mailing list
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

six is a special case, as it is provides compatibility for scripts
running different versions of python.
It is useful to be able to create 2 separate packages though, a python2
version, and a python3 version (with different package names), because
you can have both installed at the same time. It would be hard to do
that with only one package with options, unless the options changed the
package name - which would then make it harder to manage with tools.

We have both python2 and python3 versions of six in a single package in -
current and it works just fine. I don't see why the package would need to be
treated differently from other python libs. What am I missing here?

Grs,
Heinz

[Benjamin Trigona-Harany]

Post by Heinz Wiesinger
We have both python2 and python3 versions of six in a single package in -
current and it works just fine. I don't see why the package would need to be
treated differently from other python libs. What am I missing here?
Grs,
Heinz

I don't think you are missing anything. As long as the *version* of a
Python module is the same for Python 2 and Python 3, then it makes sense
to have them in a single package or SlackBuild. As I mentioned in my
other email, there are rare cases where this isn't possible: IPython
won't go above 5.x for Python 2 but is on 7.x for Python 3.

Otherwise, keeping them together is usually the way to go.

Ben
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-***@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Frédéric Falsetti]

oups, sorry, thanks Matteo and Ben

On Tue, 30 Oct 2018 10:59:44 -0700

Post by Benjamin Trigona-Harany

Post by Heinz Wiesinger
We have both python2 and python3 versions of six in a single package in -
current and it works just fine. I don't see why the package would need to be
treated differently from other python libs. What am I missing here?
Grs,
Heinz

I don't think you are missing anything. As long as the *version* of a
Python module is the same for Python 2 and Python 3, then it makes sense
to have them in a single package or SlackBuild. As I mentioned in my
other email, there are rare cases where this isn't possible: IPython
won't go above 5.x for Python 2 but is on 7.x for Python 3.
Otherwise, keeping them together is usually the way to go.
Ben
_______________________________________________
SlackBuilds-users mailing list
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-***@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[David Woodfall]

On Wednesday 31 October 2018 09:54,

Post by Heinz Wiesinger
We have both python2 and python3 versions of six in a single package in -
current and it works just fine. I don't see why the package would need to be
treated differently from other python libs. What am I missing here?
Grs,
Heinz

I don't think you are missing anything. As long as the *version* of a Python module is the same for
Python 2 and Python 3, then it makes sense to have them in a single package or SlackBuild. As I
mentioned in my other email, there are rare cases where this isn't possible: IPython won't go above 5.x
for Python 2 but is on 7.x for Python 3.
Otherwise, keeping them together is usually the way to go.
Ben
_______________________________________________
SlackBuilds-users mailing list
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

there seems to be a variation  of support in the python scripts. Having the script produce both pthon2 and
python3 files would be useful. I am in the process of updating thonny ( a python ide) which has new deps,
and pyserial is an example where it only does python2. Repeating the python setup.py install --root=$PKG in
the slackbuild
but changing python to python3 fixes that, but I created a separate slackbuild,(not yet submitted) because
most of the python packages I have seen so fave have two separate packages, a pkgname and a
python3-pkgname.
Should I make new python packages create both sets of files, or create separate python2 and python3
packages ?
(i'm working on mypy and mypy_extensions at the moment)
regards, Tim

What I did with pudb, the python debugger, is have options for
building either or both, so the user can decide. If someone only
wants to debug python3 code I'm not going to foist an extra load of
python2 code on them.

Dave
--

You or I must yield up his life to Ahrimanes. I would rather it were
you. I should have no hesitation in sacrificing my own life to spare
yours, but we take stock next week, and it would not be fair on the
company.
-- J. Wellington Wells

[B Watson]

On 10/31/18, Tim Dickson via SlackBuilds-users

documentation, but if you use two build scripts, the documentation would
need to be in different places to avoid loosing it if you had both
installed, and just removepkg one of them.

That wouldn't happen. removepkg would notice the files exist in another
package and it wouldn't remove them.

That said, it'd be cleaner for each package to have its own set.

Since 15.0 is going to ship python3, maybe combining all the <thing>
and python3-<thing> builds is the way to go. No more "this requires
blahblah, built with python3 support" in READMEs, you'd be able to just
look at the REQUIRES and install those packages.

Speaking as someone who only installs python & its modules as dependencies
for apps I want to run, that would make life simpler.
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-***@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/