Python and Ubuntu versions

[אורי‎]

Hi,

I have a production server with Ubuntu 18.04 LTS (currently upgraded to
Ubuntu 18.04.5 LTS) and I use Python in virtualenv - currently Python
3.6.9. I'm using Django and I read that from Django 4.0, a minimal version
of Python 3.8 will be required. I would like to know how I use the latest
version of Python (3.10 or 3.9) with my production server - do I have to
reinstall a new server with the latest Ubuntu LTS version? Or do I have to
upgrade my current server's Ubuntu version by upgrading the same machine?
Or should I keep the Ubuntu version and only upgrade Python? I'm also using
other software such as PostgreSQL which is currently psql (PostgreSQL)
10.17 (Ubuntu 10.17-0ubuntu0.18.04.1). Should I upgrade this too? And what
is the risk that things will not work after I upgrade this?

Thanks,
אורי
u...@speedy.net

[Chris Angelico]

It's probably easiest to build Python from source. Clone the source
repository from GitHub, and build it right there. You can then upgrade
your venv to use it, reinstall packages, and everything should work.

ChrisA

[Cameron Simpson]

On 23Jul2021 07:54, אורי <u...@speedy.net> wrote:
>I have a production server with Ubuntu 18.04 LTS (currently upgraded to
>Ubuntu 18.04.5 LTS) and I use Python in virtualenv - currently Python
>3.6.9. I'm using Django and I read that from Django 4.0, a minimal version
>of Python 3.8 will be required. I would like to know how I use the latest
>version of Python (3.10 or 3.9) with my production server - do I have to
>reinstall a new server with the latest Ubuntu LTS version? Or do I have to
>upgrade my current server's Ubuntu version by upgrading the same machine?
>Or should I keep the Ubuntu version and only upgrade Python? I'm also using
>other software such as PostgreSQL which is currently psql (PostgreSQL)
>10.17 (Ubuntu 10.17-0ubuntu0.18.04.1). Should I upgrade this too? And what
>is the risk that things will not work after I upgrade this?

I would install a totally separate Python from the vendor (ubunut)
provided one. This prevents subtle changes to what the OS has been
tested against.

You can built Python from source and install it, for example with a
prefix like /usr/local/ptyhon-3.10. That gets you a different version;
nothing in the OS stuff will try to use it, but you use it to invoke
your Django app.

Both Python and PostgreSQL tend to be very forward compatible - your
code should not need to change.

By making a separate install you're avoiding breaking OS stuff.

Do the build and install as yourself. I usually do the install step by
making the install directory as root, then chowning it to me. Then you
can do the install as you - this has the advantage the you're
unprivileged and can't accidentally damage the OS install.

If you're just doing this for personal use then you can of course just
install it in your own home directory, not root owned steps required at
all.

Cheers,
Cameron Simpson <c...@cskk.id.au>

[Chris Angelico]

On Fri, Jul 23, 2021 at 7:48 PM Cameron Simpson <c...@cskk.id.au> wrote:
> Do the build and install as yourself. I usually do the install step by
> making the install directory as root, then chowning it to me. Then you
> can do the install as you - this has the advantage the you're
> unprivileged and can't accidentally damage the OS install.

That's interesting, in that it leaves you vulnerable to accidentally
damaging your alternate installation, but you're putting it into a
directory that normally would look privileged. I'd be inclined to
leave /usr as a privileged directory, and do this sort of installation
entirely within ~/bin or something equivalent. But hey, this is the
flexibility of Unix file system permissions!

ChrisA

[Mike Easter]

For those who are following this thread on a conventional news server,
there are missing parts which came from the python-list mailing list
instead.

For those who prefer an nntp access to the mailing list, the
corresponding group on news.gmane.io is gmane.comp.python.general.

Posting there is unconventional.


--
Mike Easter

[Terry Reedy]

On 7/23/2021 12:54 AM, אורי wrote:
> Hi,

>
> I have a production server with Ubuntu 18.04 LTS (currently upgraded to
> Ubuntu 18.04.5 LTS) and I use Python in virtualenv - currently Python
> 3.6.9. I'm using Django and I read that from Django 4.0, a minimal version
> of Python 3.8 will be required. I would like to know how I use the latest
> version of Python (3.10 or 3.9) with my production server - do I have to

3.9 is the latest production release. Others packages should all be
available. 3.10 is still in beta, and updated versions of some packages
will not be available for a few months after its release in Sept.

--
Terry Jan Reedy

[Cameron Simpson]

Rereading this, maybe I was unclear. This is for install directories
like /opt/Python-3.whatever or /usr/local/python-3.whatever. Create the
install point, chown, install as yourself.

I agree about the risk of future mangling - there's a good case for
chowning it all to root _after_ the install. I'm just trying to do the
install itself in an unprivileged mode.

Probably for the OP, the simplest way is a local install as themselved,
eg in ~/opt/python-3.whatever. Not rootneed needed at all, and a few
symlinks in ~/bin (or adding ~/opt/python-3.whatever/bin to $PATH) are
all that's needed to make use of it.

Cheers,
Cameron Simpson <c...@cskk.id.au>

[Chris Angelico]

On Sat, Jul 24, 2021 at 9:03 AM Cameron Simpson <c...@cskk.id.au> wrote:
>
> On 23Jul2021 19:51, Chris Angelico <ros...@gmail.com> wrote:
> >On Fri, Jul 23, 2021 at 7:48 PM Cameron Simpson <c...@cskk.id.au> wrote:
> >> Do the build and install as yourself. I usually do the install step by
> >> making the install directory as root, then chowning it to me. Then you
> >> can do the install as you - this has the advantage the you're
> >> unprivileged and can't accidentally damage the OS install.
> >
> >That's interesting, in that it leaves you vulnerable to accidentally
> >damaging your alternate installation, but you're putting it into a
> >directory that normally would look privileged. I'd be inclined to
> >leave /usr as a privileged directory, and do this sort of installation
> >entirely within ~/bin or something equivalent. But hey, this is the
> >flexibility of Unix file system permissions!
>
> Rereading this, maybe I was unclear. This is for install directories
> like /opt/Python-3.whatever or /usr/local/python-3.whatever. Create the
> install point, chown, install as yourself.
>
> I agree about the risk of future mangling - there's a good case for
> chowning it all to root _after_ the install. I'm just trying to do the
> install itself in an unprivileged mode.

Ah, I see what you mean. In that case, it's probably fine, but I'd
just take the simpler approach and "sudo make install" (or altinstall
as the case may be).

> Probably for the OP, the simplest way is a local install as themselved,
> eg in ~/opt/python-3.whatever. Not rootneed needed at all, and a few
> symlinks in ~/bin (or adding ~/opt/python-3.whatever/bin to $PATH) are
> all that's needed to make use of it.
>

Yeah, exactly.

ChrisA

[Cameron Simpson]

On 24Jul2021 09:22, Chris Angelico <ros...@gmail.com> wrote:
>On Sat, Jul 24, 2021 at 9:03 AM Cameron Simpson <c...@cskk.id.au> wrote:
>> Rereading this, maybe I was unclear. This is for install directories
>> like /opt/Python-3.whatever or /usr/local/python-3.whatever. Create the
>> install point, chown, install as yourself.
>>
>> I agree about the risk of future mangling - there's a good case for
>> chowning it all to root _after_ the install. I'm just trying to do the
>> install itself in an unprivileged mode.
>
>Ah, I see what you mean. In that case, it's probably fine, but I'd
>just take the simpler approach and "sudo make install" (or altinstall
>as the case may be).

Ah, but to me this is the moral equivalent of:

wget random-install-script-url | sh

Ideally I'd be doing the install, and arguably the build, as a third
user, neither root (keep the system intact) nor myself (my data! mine!
don't you touch it!)

>> Probably for the OP, the simplest way is a local install as themselved,
>> eg in ~/opt/python-3.whatever. Not rootneed needed at all, and a few
>> symlinks in ~/bin (or adding ~/opt/python-3.whatever/bin to $PATH) are
>> all that's needed to make use of it.
>
>Yeah, exactly.

Aye.

But they seemed to be on the route of installing over the system Python,
and I was trying to talk them down to just a "system wide but off to the
side" install.

Cheers,
Cameron Simpson <c...@cskk.id.au>

[Chris Angelico]

On Sat, Jul 24, 2021 at 9:52 AM Cameron Simpson <c...@cskk.id.au> wrote:
>
> On 24Jul2021 09:22, Chris Angelico <ros...@gmail.com> wrote:
> >On Sat, Jul 24, 2021 at 9:03 AM Cameron Simpson <c...@cskk.id.au> wrote:
> >> Rereading this, maybe I was unclear. This is for install directories
> >> like /opt/Python-3.whatever or /usr/local/python-3.whatever. Create the
> >> install point, chown, install as yourself.
> >>
> >> I agree about the risk of future mangling - there's a good case for
> >> chowning it all to root _after_ the install. I'm just trying to do the
> >> install itself in an unprivileged mode.
> >
> >Ah, I see what you mean. In that case, it's probably fine, but I'd
> >just take the simpler approach and "sudo make install" (or altinstall
> >as the case may be).
>
> Ah, but to me this is the moral equivalent of:
>
> wget random-install-script-url | sh

Ehhh, it's not nearly that bad. The biggest risk with the wget command
is that, even if you fully trust the source, all it takes is one small
network issue and you're running a half a script.

> Ideally I'd be doing the install, and arguably the build, as a third
> user, neither root (keep the system intact) nor myself (my data! mine!
> don't you touch it!)

Oh, definitely the build is done as a non-root user. (I usually do
that as my own user for simplicity, though.) And while I can see the
benefits to installing as a dedicated separate user, it's also just
way too fiddly, so I just sudo it and do things the easy way :)

(That is, assuming I'm installing into /usr. If it's installed outside
of those sorts of directories, then root won't be involved at all -
for instance, if I'm developing OBS Studio, I'll build it into
~/tmp/obs/bin and its friends, and it'll all be done as my own user.)

> >> Probably for the OP, the simplest way is a local install as themselved,
> >> eg in ~/opt/python-3.whatever. Not rootneed needed at all, and a few
> >> symlinks in ~/bin (or adding ~/opt/python-3.whatever/bin to $PATH) are
> >> all that's needed to make use of it.
> >
> >Yeah, exactly.
>
> Aye.
>
> But they seemed to be on the route of installing over the system Python,
> and I was trying to talk them down to just a "system wide but off to the
> side" install.
>

Fair enough. And I absolutely agree with NOT installing over the
system Python, although that's usually not going to happen anyway
(since this is a different minor version).

ChrisA

[Terry Reedy]

Huh? If you read this, posting from gmane works fine!


--
Terry Jan Reedy

[Mike Easter]

In the past, old gmane required posting w/ a good email because the
gmane server required you to receive an email and self-approve your posting.

So, are you saying that gmane didn't require you to approve/authorize
your msg?

I was able to read your msg on both gmane's and my conventional nntp. I
replied on my conventional NIN because my typical config (and my config
on the experimental gmane acct) was w/ a bogus/invalid email, and
previously an accidental attempt to post on gmane that way failed.


--
Mike Easter

[Mike Easter]

I'm reading a msg that suggests that if you a sub/ed to the py-list,
that takes care of the gmane 'unconventional' problem.


--
Mike Easter

[Mike Easter]

Mike Easter wrote:
> In the past, old gmane required posting w/ a good email because the
> gmane server required you to receive an email and self-approve your
> posting.

The old gmane also obfuscated the email of someone posting that way.
So, you needed to configure your agent to use a good email, but gmane
used a strategy to mitigate exposing your email to spam.

--
Mike Easter

[אורי‎]

Thank you.
אורי
u...@speedy.net

> --
> https://mail.python.org/mailman/listinfo/python-list
>

[Peter J. Holzer]

On 2021-07-23 15:17:59 +1000, Cameron Simpson wrote:
> On 23Jul2021 07:54, אורי <u...@speedy.net> wrote:

> >I have a production server with Ubuntu 18.04 LTS (currently upgraded to
> >Ubuntu 18.04.5 LTS) and I use Python in virtualenv - currently Python
> >3.6.9. I'm using Django and I read that from Django 4.0, a minimal version
> >of Python 3.8 will be required. I would like to know how I use the latest
> >version of Python (3.10 or 3.9) with my production server

[...]

>
> I would install a totally separate Python from the vendor (ubunut)
> provided one. This prevents subtle changes to what the OS has been
> tested against.
>
> You can built Python from source and install it, for example with a
> prefix like /usr/local/ptyhon-3.10. That gets you a different version;
> nothing in the OS stuff will try to use it, but you use it to invoke
> your Django app.

If you are using mod_wsgi to run your Python apps you will probably have
to rebuild that as well. The mod_wsgi supplied with Ubuntu uses the
system Python and at least a cursory glance through the docs doesn't
reveal a way to change that.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | h...@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"