A slight annoyance with Python install setup

[courtage]

I do a lot of stuff in Python these days, and I need to match my installed Python version on my dev Puppy to my production server's.

While it's great that fossapup64 has Python3.8 (actually 3.8.2) installed as default, I need to run 3.8.3 (& quite soon probably 3.9.x).

This is easy enough - I compile my own, it only takes a few mins.

BUT

the default install -prefix for the pre-installed fossa Python is /usr whereas Python's *own* default is /usr/local

OK, so it's easy enough for me to work around when compiling & installing Python but I can't help wondering why an installation location was chosen that actually conflicts with the preferred location of the package itself.

This is probably something that needs to be considered for future Puppys (too late to retrofit on fossa tho, I imagine)

[Grey]

This is NOT the default Python prefix, but pretty much anything you compile yourself. In addition, you can specify a directory when compiling. Typically:
--prefix=DIR use this prefix for installing [/usr] [/usr/local]

[courtage]

Except that it is the default prefix

As we can see here.

Code: Select all

root# ./configure --help
`configure' configures python 3.8 to adapt to many kinds of systems.

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.

Configuration:
  -h, --help              display this help and exit
      --help=short        display options specific to this package
      --help=recursive    display the short help of all the included packages
  -V, --version           display version information and exit
  -q, --quiet, --silent   do not print `checking ...' messages
      --cache-file=FILE   cache test results in FILE [disabled]
  -C, --config-cache      alias for `--cache-file=config.cache'
  -n, --no-create         do not create output files
      --srcdir=DIR        find the sources in DIR [configure dir or `..']

Installation directories:
  --prefix=PREFIX         install architecture-independent files in PREFIX
                          [/usr/local]
  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
                          [PREFIX]

By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc.  You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.

so, in fact, you are quite quite wrong

[Grey]

And how does this contradict the fact that most programs use /usr/local by default?
/usr/local is needed to test newly compiled programs. And the finished, official release usually goes to /usr. But I also sometimes ignore it.

[OscarTalks]

The prefix /usr/local is set as default within the source code, but the idea is that the builder (person compiling) should configure the prefix in accordance with the objectives.
It is fairly common (certainly in Puppy) for original system files to be under /usr and for packages installed from source to go under /usr/local but you need to be aware that files of the same name under /usr will have priority over those under /usr/local
So prefix=/usr/local should not be used for attempted version upgrades for example, as original /usr/bin/python would still be recognised and newer /usr/local/bin/python ignored.
When compiling in Puppy it is often recommended to use prefix=/usr anyway, although for a new package there may be reasons to go with /usr/local
The point is though that having /usr/local as the default within the source does not mean that it must be the default prefix within a distro and although it is an interesting discussion I do not think Puppy builders would look at issuing a Puppy version with python included under that prefix.

[CatDude]

Hello Oscar

It is fairly common (certainly in Puppy) for original system files to be under /usr and for packages installed from source to go under /usr/local but you need to be aware that files of the same name under /usr will have priority over those under /usr/local

Are you sure about that last bit, as i get the opposite behaviour in Fatdog64-811 here.

It appears to read the PATH from left to right.

Code: Select all

# echo $PATH
/usr/local/bin:/usr/bin:/usr/sbin:/bin:/sbin:/opt/qt5/bin
# 
# whereis psip
psip: /usr/bin/psip
# 
# which psip
/usr/bin/psip
#  

After adding a duplicate of psip into /usr/local/bin
i now get the following:

Code: Select all

# whereis psip
psip: /usr/bin/psip /usr/local/bin/psip
# 
# which psip
/usr/local/bin/psip
# 

Just saying like.
Though my setup could be a bit strange, but i don't recall changing the PATH in any way.
.
.

[bigpup]

Fatdog is not Puppy Linux!
What is done in Fatdog has nothing to do with what is standard for Puppy Linux.

Fatdog is on this forum, because the forum administrator allows it to be on the forum.
It is Puppy like, but not true Puppy Linux.

Is Fatdog64 considered as Puppy Linux?
A: No. It was originally forked from Puppy Linux 4.0, but it has since took a different path (of doing the same thing).

Fatdog is Puppy like, but does things the Fatdog way.

[OscarTalks]

Are you sure about that last bit, as i get the opposite behaviour in Fatdog64-811 here.

Hello CatDude,
It was my understanding of how the priorities are set up in Puppy. Certainly in the older ones (and slightly older ones) which I use the most.
I believe PATH and LD_LIBRARY_PATH are set in /etc/profile are they not? There may be other ways of influencing them system-wide but I am not sure about that.
Anyway, I booted into frugal FossaPup just now and it looks like this:-

Code: Select all

root# echo $PATH
/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/root/my-applications/bin:/usr/games
root# echo $LD_LIBRARY_PATH
/lib:/usr/lib:/root/my-applications/lib:/usr/local/lib
root#

So different from FatDog it seems, though perhaps there is a rationale for saying that anything user-installed should take priority over original system bins and libs.

[CatDude]

Hi

@ bigpup
Fair enough chap.

@ Oscar
I never realised that the PATH's were different between the two of them mate.

I'll shut up and crawl back under my rock.

.