Common lisp has one too: quicklisp... and it too only creates modifications in the ~/quicklisp folder.

Regardless of the language, though, I have to type something at the cli to activate its tool... and as long as the output is directed to an "alternate root", a slackpkg can be made from the alternate root, and then installed, even if to the users ~/.local/bin: direct output to /altroot/home/saiduser/.local/bin, change to the /altroot directory, and run makepkg. Using upgradepkg will then upgrade that language's development libraries accordingly.

This process can be scripted for a slackware purist. If it was not scripted, I concede that going through that process would certainly be inconvenient everytime 'pip install --upgrade' was run, which could be daily when working with lots of libraries...

A compromise: use lxc, maintaining the host system with pkgtools / slackpkg, and creating container for python developmenmt, and running pip within that container.

1 members found this post helpful.

With the poll having closed, I will offer my opinion of 3.10 as the wise choice: already entered; OS packages already built for the new version; longest support timeline.

As a longtime Python developer, much of that time on a Mac, I learned long ago to keep my desired version of Python under /usr/local. Mac OS X (as they used to call it) tended to have an outdated version of Python in the system directory. Slackware current may have the opposite problem. My solution works either way. I recommend configuring with `--enable-shared --enable-optimizations` for most users.

Although you can make a SlackBuild for everything, it sometimes doesn't make sense. Python packages are already managed with their own system. You can install specific versions, uninstall them. If it makes people feel better to wrap a slackbuild around it, fine, but its a huge waste of time to duplicate a native package management system. For those Python applications that have lots of specific dependencies, I would suggest just embedding the dependencies inside the top level application slackbuild with "pip install <package>=version". That way if the package is important to you, you can be sure the dependencies are satisfied *for that particular package*. Its impossible to generally satisfy the dependencies for all specific applications. The only way to do that is to use containers, as someone has already mentioned.

2 members found this post helpful.

I agree with this sentiment. I suspect Slackware ships OS packages for Python packages only to provide dependencies to other Slackware packages. Otherwise, OS packages for Python, Ruby, etc packages make sense only in environments without build tools commonly installed, and most packages won't even make use of them (written in pure Python, etc). Termux comes to mind for Python packages like numpy. It would surprise me to find an appreciable number of Slackware users without the required build tools installed.

You really think Pat building those few dozen python packages was the delay for 15.0? You need a reality check.

Do you know how long it takes me to version bump a SlackBuild? 5 seconds (if that) to run my version bump script and pass the new version to it. It will then automatically update the download links, calculate and update the md5sum, and update the versions in the .info and .SlackBuild. Then I do a quick run of the SlackBuild and if everything works, I push the changes to my online repo and make a PR against SBo's repo. If it's a slow building program, it might take me 5 minutes, most of that waiting for downloads or compiling. Actual time to be doing anything active with it is less than a minute.

It doesn't make sense to you, but I don't want untracked files in my filesystem and I don't want python modules only available to my user. The *only* solution for that is to install python (and perl) software as Slackware packages. If you don't want to do that, it's fine. Everyone is the admin of their own box.

It's not native to Slackware, and that is many people's issue with it. It completely leaves pkgtool in the dark and possibilities for overwriting or removing files that might be duplicated in packages is a very real possibility.

This method doesn't work with SBo's current policies of requiring all dependencies not included in Slackware to be available on SBo and requiring SlackBuilds to be able to be used offline (you can't make any internet connections with the SlackBuild itself). There are a lot of people who maintain their own SlackBuilds that don't conform to SBo standards, but you'd either need SBo to change policies or find somewhere else to host the builds (maybe make a competing site that doesn't restrict internet connections within the SlackBuild).

Long story short, your suggestion goes against the packaging standards that Slackware and SBo rely on. There are certainly people that don't follow those standards, and that's ok (they're the admin of their own box), but you're unlikely to get any traction in making this a standard in Slackware or SBo.

11 members found this post helpful.

What is the threshold for this poll? It doesn't seem to end, so I am guessing it is based on number of votes? I will not be voting because I honestly don't know, or care whatever is included is included. I just wonder when Pat will decide to make his decision.

The poll is already closed. Nobody else can vote on it.

Oh ok, I did not see / notice (dopey me ). Cool so it is settled then, 3.10 it is.

The Changelog is the deciding factor here. Until I see a dedicated changelog file for 15.0 I assume nothing.

this should be on sbo

1 members found this post helpful.

I guess I can go and actually take the time to figure out updating md5sums for multiple downloads and add it to SBo once submissions open if people want it. I was lazy when I decided to code this and just went for the easy route, as I only have one or two SlackBuilds that have multiple downloads, and they don't update very often.

2 members found this post helpful.

@Battered Fish

What has been discussed, and repeated, is this aspect of why people do not (like to) use the python pip-system:

It would be helpful if you could suggest how the pip-system could collaborate with the Slackware package tools.

Perhaps (although is not Kiss) having a slotted package like in Gentoo could not be a very bad idea for packages that are a moving target like python.
Slackware is not Gentoo but perhaps something like a band aid could me usable. i know if a package is compiled for a specific version of python would be a problem but al least in this way some scripts could work.
My first question in this forum was if Slackware had a program similar to Gentoo s eselect, i was asking of wine and a user called Orbea show me a script he made that make symlinks.
https://notabug.org/orbea/SlackBuild...er/system/wine

i know this is very different but perhaps a more elegant solution could be possible.
perhaps im drinking too much.

Since there are some particular python package dependencies that are needed for the Slackware distribution as a whole, they could all be wrapped up in a single "python-extras" slackbuild script, and call out to "pip install --no-deps SomePackage1-1.0.4.tar.gz; pip install --no-deps SomePacakge2-1.2.tar.gz; ...". Python already has a native package management system and distributions like Arch and Gentoo suggest you use it to manage python packages. Why you'd want to piecemeal replace package by package with slackbuilds scripts is beyond me.

Its not the problem, but I surmise its a symptom of a problem. Since noone has stated the reason for the delay it might as well be a few dozen python packages.


For major packages there can be many python dependencies. To install all those manually, and perhaps create new slackbuilds for many, isn't trivial. In fact, its tremendously tedious. As was said previously, the only way around that it so use containers or virtual environments for each major package in which using pip to resolve the dependency versions is the way to go. If someone wants to wrap the whole virtual install in a slackbuild, great.


Its not a sensible general solution for the co-existence of significant python applications.

Yes, absolutely true. All the interpreters have their own package/module management systems which people should be using to maintain packages in those languages. Wrapping slackbuilds scripts around major packages for virtual install with all their dependencies pulled in by the script would work and make life simple.

SBo's policies don't make sense in the context of interpreter package management.

Yes, no doubt it does. Change is hard, and there is always hope (except for Slackware 15.0 being released, hope on that ran out awhile back ;-).