Please excuse a possibly daft question but...

As a Slackbuild would possibly/probably be a less than cutting edge package while pip would be the newest shiny, why would anyone want the combination of the latest Python and Slackbuilds?

Wouldn't they be two different camps?

3.10 and pip
3.9 and Slackbuilds

?

Thanks, you just proved my point. :-)

No different camps needed. It is quite easy to have 3.10 and Slackbuilds. The major issue is that by pip-installing one hands over control to the installer of what's going onto the box; it drags in dependencies (therefore the above advised add-on to use: `--no-deps`), overwriting current ones in favor of the required (acc. to the program) version. Many people (incl me) like to make SlackBuilds for modules (incl. for these dependencies).

Once made, upgrading the python module is a piece of cake; after downloading the source file from pypi.org, only change the version nr in the SlackBuild (plus md5sum when needing an info file for sbopkg; in this respect it is helpful to use a readable web address for the source instead of a direct copied link (as suggested here)).

By creating a SlackBuild, one creates a package of a python module that can then be installed on a large number of other boxes with the same setup. (Pip only deals with the box the install goes on).

One does not need to try a pip-install to find dependencies, most of them are described in 'requires.txt' found in the 'egg.info' or the 'setup.cfg' in the shipped source (tar.gz) file of the module on pypi.org.

Many python SlackBuilds on Sbo are quickly updated when needed. This all depends on the maintainers. It would be helpful if the build-scripts get standard separated in python2 and python3 only scripts. That would make it more easy to keep track of dependencies (via the info files) and enables moving on.

Because of python3.10 developers that still want their program working will sort out bugs caused by the change. (Coding-wise, the move from python2 to python3 was more painful than that from 3.9 to 3.10. And we/most of us survived that one ;-)

5 members found this post helpful.

I am another that does not use CPAN or PIP - or anything that has potential to drag in anything from ... where ever, but prefer to build modules with Slackbuilds as well. I'll work with the version Pat decides to ship.

1 members found this post helpful.

Or virtualenv ? I use that for fairly less than a hundred modules...

The slackware way is to use pkgtools / slackpkg to maintain system: even when customizing slackware, custom slackware packages do I build, though sometimes seeming inconvenient--after scripting the process, it's just all in a days work...

3 members found this post helpful.

Done deal what ever Pat wants to use. 3.9 no longer builds so I am sure you will just complain and moan like me then use the tools given.
As you will note pip2 isn't on the file list. but it is there.
So oH well. 2.7 legacy should stay in it as long s there are several thousand programs that need it.
I would prefer that Pat sets his python link to python3 not python2.
Real issue is the order of install and the guy making the package.
That is the first thing I do when updating.
As you can see
Not on FILELIST.TXT
and
They can live together. just what one do you want as default.

That becomes an issue for people like me that use the
For modules I do not want to install but yet use to build with.
since pip3 is default and python2 is default pyhon.
I have to remember to set the variable for the builds.
But I really do think it is time to make python3 default and pip3 default.
Just my thought.

1 members found this post helpful.

I disagree the fact is pyhon packaging system was built to coexist with the admin.
You can do all the ~/.local/bin and ~/.local/lib for python sites and eggs.
You need to build a program and keep your system inline with admin. AKA Pat then use the tools Pat gave you.
use them as an user. then when ready to build the package then use the pkgtool program.

These are all tools so use the tools. That Pat gave you.
you want to write scripts.
that's fine.
But this will not give you the ever changing dependencies and updates.
This is why building as a user. Is a big deal with the python people.
As I explained before.
remember leave admin pristine and install ~./local
none of these are system libraries.

The problem solved was simple. 3.10.0 did not look for 3.09 sites I can look at the scripts figure it out. Now I figured it out. just rebuild your packages and all went good.

This was the issue I had some 3.7, 3.8, 3.9 then 3.10.0 did not look into 3.9 and lower.
Once I figured it out was fix. just rebuilt my packages all done.
Use what ever it takes to fix bugs.
All simple when you figure it out.

perfect !

Attached Thumbnails

 

(3+3)66, the number of the beast!

To be honest I didn't read the entire thread, so I might be repeating someone else here: The fact that 3.10 broke so many 3.9 scripts seems to be a mismanagement (if at all) on the Python devs' side. If they see this fit then they must be expecting active 3.x users to upgrade their scripts to 3.10, otherwise it would be a mess really. Will 3.10 hold as the "standard" 3.x version? We can't know, it is up to the Python team. But it certainly has better chance (and longer life expectancy) than 3.9, therefore I would support Slackware going for 3.10.

Maybe read the thread. A lot of 'breakage' (also see the thread 'SBo scripts not building on current') is mostly reflecting user's experience before the required recompiling of packages and updating of versions (to match 3.10).

1 members found this post helpful.

Thanks for the information (I just didn't have the time to go through it all ). Some real breakages (upstream) can happen though, and in those cases the newer version would be preferable for long term support.

On a side note, although I kind of grew impatient with the new release I am happy that the soon-to-be-relased Rust 1.56 which introduces Rust 2021 support will make it into the new Slackware release. Some pretty important additions were made since the 2018 edition.

1 members found this post helpful.

The beast is Python!
Why have we come to depend so much on python? Everything nowadays uses python, and python sucks

1 members found this post helpful.