Hello!

Due to the switch from ucs2 to ucs4 for python2 in slackware-current, I'm recompiling a bunch of python2-packages. Since I'm also using python3, my current mode of compiling is to include an "if-python3-is-installed-switch" in my SlackBuilds -- this means I'm also unnecessarily recompiling the python3 stuff.
A better approach would probably be to split the packages in a python2 and python3 package.
Then however I'm faced with the decision how to name the packs. Should I compile the python3 stuff as "python-pack3" and the python2 as "python-pack" or the other way around?
On slackbuild.org the trend seems to be to split as "python-pack3" which makes sense since the python2-packs in slackware are all named "python-pack", but there are also a bunch of packs with the "if-switch".

This python3-dilemma has been bothering me for a while ... so how are you guys handling this?

I posed this question on the SBo thread, and it seemed the general consensus is it is better to separate the packages following the naming scheme: either package or python-package for python2 and python3-package for python3. However, there's not been any official rule or template provided by the SBo admins, so maintainers are currently free to use whatever method they prefer.

1 members found this post helpful.

Okay!
So python3-package it is.
Whats with the executables in the bin/-directories?

I haven't ran into any situations like that with the packages I use. I'd imagine you should probably supplant any python3 versions with that in the name, but that is just my personal preference.

If there is the possibility of a python2 and python3 version, I feel that python3 should always be labeled as such, at least until Slackware changes the default python to python3 (then all python2 stuff should have python2 in the name and python3 should not have anything specific).

But, since this isn't the official place to discuss SBo stuff, it might be better to take this question to the SBo thread or to their mailing lists. I'd imagine the mailing lists would get better feedback from more package maintainers. This discussion could lead to a policy change, ensuring pyhton packages are consistent in their handling of python2 and python3 (whatever that consensus might be).

1 members found this post helpful.

Thanks, that'll buy us some time to think of a good answer to a very good question

1 members found this post helpful.

I personally think its best to just have both python3 and python2 modules in the same package. If python3 is installed then the python3 modules will be installed, if not only the python2 modules. Its a lot less maintenance that way.

The problem I see with that is if someone installs python3 after they've built a lot of python2 modules, then people might run into issues if they think the dependencies have already been fulfilled but they require rebuilds to build python3 versions.

Having them separate completely removes this situation. Then people are only building python3 (or python2) packages only when they need to, rather than building every package as both python2 and python3.

1 members found this post helpful.

I think that is just common sense, how are you going to build python3 modules without python3? Anyways this is Slackware, everyone should be able to take a quick glance at /var/log/packages and see if there are any python3 modules for a program.

The issue is when someone already has a python package built (that supports python3) without having python3 installed (whether they realized it or not), then, when a package requires a python3 version of that dependency, they may think they already had it installed and then be confused when the build fails or the program fails to start.

I suppose the generic answer would just be to rebuild all the dependencies, but if they're only building python2 or python3 versions when they're needed, then the problem doesn't even exist. There's been a few programs I've done SlackBuilds for that didn't have python3 support included, so I made a python3 version and offered it to the maintainer. For those dependencies that do support python3 by an if/then statement, I specifically noted in the main program's README that if those dependencies were installed prior to installing python3, they would need to be rebuilt. But, how many people read the READMEs (I know everyone should, but it doesn't always happen). If there were only python3 versions, then I wouldn't need to worry about specifying anything in the README and it simplifies the build process for a lot of people, while adding only a few minutes (if that) of extra work to the maintainer when they need to upgrade versions, but you should only need to copy/paste the new url, md5sum, and version between the two packages.

But, this is why this discussion should take place I know I don't speak for everyone with my views, and it'd be good to get a consensus from package maintainers, SBo admins, and users, so the SBo admins can decide how they want to proceed with plenty of input from the community. Thanks for your thoughts, orbea

When I submit slackbuilds that can either support python2 or python3 I use this and add a note to the slackbuild that python3 is an optional dependency.

I expect users to understand that python3 modules will not be installed if they do not have python3. This is the same as any c based script where if you want to add an dependency the program will have to be recompiled. Slackware has always provided complete packages rather than splitting them up for arbitrary reasons like debian, red hat or arch does and its far easier to add one if statement to a script than to maintain two nearly identical versions of the script.

The exceptions to this are programs that exist in a full slackware install as python2 modules, but sometimes python3 modules are still needed for scripts at SBo. An example would be dbus-python3. Additionally there are some scripts in SBo that have both python2 and python3 versions because upstream decided to develop them as different projects, such as python-xlib and python3-xlib.

Yes, that is how most python packages that include both python2 and python3 support do it.

One of the programs I'll be submitting a SlackBuild for is acd_cli. It is based on python3 and requires a python3 version of six (among quite a few other python dependencies). The six SlackBuild has an if/then test for python3, however, no packages in SBo currently rely on six and python3 (based on grepping the REQUIRES line in the .info files -- it shows there's 42 SlackBuilds that rely on six, but none of them also require python3). So, if someone were to go build my package once it gets added to SBo, then this could be the first time they needed to build python3. Unless you read through everything, you might not even realize that six is a python package, let alone that it needs to now be rebuilt now that you have python3 installed (although, I did specifically mention that colorama, python-requests, six, and SQLAlchemy all would need to be rebuilt if they were built without python3). If there were a python3-six package, there would be no confusion and no rebuilding of packages required.

There would be very little additional work for a maintainer to manage a python2 and python3 package separately, as all that should really be required is to mirror the url, md5sum and version on the .info and the version on the .SlackBuild and the time it takes to package up both of them and submit them separately. Unless they're updating them several times a month, it really isn't that much work and alleviates a lot of confusion ensures the required dependencies are built based on the correct version of python. Plus, is it really worth it to possibly build a python2 AND python3 version of every single python package even though most people probably only need one or the other?

Then, when Pat eventually makes the change to python3 (because it will eventually happen, even if it isn't this next dev cycle), it would be easy to go in and flip all python packages based on python2 to say python2 and all the python3 packages to python (since python3 would be the default version in Slackware). This would mimic what is done with gstreamer (although, I'll admit it isn't the perfect example since the sources are actually different and require separate SlackBuilds to build them).

This is kind of going in circles, between python being included in the six slackbuild and it being in the python series it should be abundantly clear that its a python program. Additionally the error message about missing python3 modules when running acd_cli should be self explanatory as should the python3 dependency.

I'm of the mind that less is more, maintaining two directories is more time and work than one if statement and a note in the README.

Would Pat make a change to python3 or would it be more like including both python2 and python3? Maybe this has since changed, but I was under the impression that some things have not made the change to python3 yet. However the only example I can think of does not really apply to slackware given how Pat patches out the python2-mako dependency from mesa.

Also, I have submitted a few scripts that have python3 support while I have not submitted the program that requires that python3 support yet (caffeine-ng).

When Slackware starts including Python 3, this is what I'd expect to happen.

People are only going to know that six is in the python category if they search for it or start browsing through all the dependencies of that program (which is a good idea, but some programs have huge lists of dependencies many levels deep and you can easily get lost while doing it). If they use an automated tool, not all of them are going to tell them it's python based (I know sbopkg doesn't tell you the package's category). Yes, trying to use acd_cli with a python2-only version of six will error out and let you know you need a python3 version, but that could've easily been avoided by separating the python2 and python3 versions.

Researching the programs they're installing would likely alleviate these issues, but I know many, me included, who don't always read through everything before they install it. And a year or two ago, I probably wouldn't have known the difference between python2 and python3 builds, but I had to figure those out when I tried to build a newer version of lirc that had switched to python3 (lirc wasn't building in -current and I wanted it for kodi).

Yes, I realize that in my ideal version it is adding a little bit of extra work for the maintainers, but that's to highly benefit the end-users and ensure everything is built only when it needs to be. It could end up collectively saving end-users a lot of time at the cost of a few minutes of the maintainer. In the end, isn't that what SlackBuild maintainers do? Spend some extra time scripting everything to benefit other users and make things much easier?

But in the end, maintainers wouldn't be forced to support a python3 version of their python2 package if they don't want to. Another maintainer could step up and provide the python3 version as I am with python3-PyYAML. Once I finished everything and verified python3-PyYAML worked, I offered it to the PyYAML maintainer, but he was fine having me manage the python3 version. So now there is no extra work on the original package maintainer and you have no confusion as to whether you have the python2 or python3 version of PyYAML without digging into the package's content listing in /var/log/packages/.

1 members found this post helpful.

And then we'll get people in here who didn't build some or all of their packages with python3, wondering why stuff stopped working. It'll be perl-5.22 all over again

Another problem with this approach is that there is no consistent way of telling build tools that a package (e.g. lirc) needs its dependent packages (pyYAML) to have been built (or rebuilt) with a dep that would otherwise be optional (python3). Having a separate python3-pyYAML package solves this trivially.

We'll all be glad when this is over, but it may be too early at the moment to tell maintainers what to do for the long term. Python Wheels are going to be a thing, and it would be a major pain to do whatever we need to do in multiple stages.

1 members found this post helpful.