Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4

[Mark Millard]

bob prohaska fbsd at www.zefox.net wrote on
Mon May 17 15:55:21 UTC 2021 :

> The existing conflict between versions of python strikes me as more of a 
> planning problem than a software bug. It may be naive, but I don't see
> why python37 and python38 can't use distinct names for files placed in
> system directories.

You seem to be under the impression that absent having
any common file paths, things would just work. This
seems unlikely. A simplified presentation of why
follows.

Imagine two programs:

p37 that is set up for python37
p38 that is set up for python38

imagine that both use a library plib that is
not internal to each but external to both.

So should plib be built/present for python37?
python38? Both?

If both: it suggests building a huge set of python
software multiple times, once per supported version
in the range of to-be-supported python versions. (I
do assume python versions make for some degree of
incompatibility distinctions. It might be only only
some version changes have that property. But such
would not change the basic point.)

I know, for example, python39 invalidated code in
something I've built in a non-FreeBSD context. The
software had to be modified to be compatible with
both older python's and python39 (if they wanted
to support the older versions as well going
forward). (It was not a context of wanting to take
advantage of new things in the newer python. But
that kind of context is not universal.)

Most ports having a separate upstream to deal with
and having a huge number of ports makes for
port-developer and upstream-developer coordination
based solutions having great difficulties overall.

No technical-content has been presented to make these
sorts of problems disappear. With the problems being
present, it is a matter of working in a way that
avoids running into the problems or with dealing with
fixing things when the problems occur. I've done both
basic styles over the years and recognize tradeoffs.
I'm happy to help someone explore one of the ways
in which poudriere can be an alternative. It is not
for me to declare how well it would end up fitting
their goals, context, preferences, and so on vs.
other alternatives overall.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)