duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] installing different versions locally


From: Kenneth Loafman
Subject: Re: [Duplicity-talk] installing different versions locally
Date: Tue, 9 Apr 2024 10:34:49 -0500

On Mon, Apr 8, 2024 at 6:46 AM <edgar.soldin@web.de> wrote:
On 07.04.2024 17:52, Kenneth Loafman wrote:
> Hi ede,
>
> Welcome to my life!
>
> I don't recall having pip install requirement for us.  I know with pipx you have to install them separately.  The README agrees with you.  Very confusing.

not really a req per se, but as i knew that pip installation works flawlessly over other methods i chose that and a dedicated venv to test that specific version.

> All I know is that when Ub24 hits there are going to be a lot of issues.  venvs will be mandatory to install duplicity, except the ancient duplicity of choice for the repo.

on the plus side, dependency hell limited to us and us alone. i'd be interested in how venvs are supposed to be set up conveniently, systemwide or if that concept only target installations per user.

> pipx works back to Ub20 for current duplicities.
>
> pip is only working on Ub22 and above for the current version.

i'd assume that we could create a venv with current pip on any platform even before Ub22, or?

> If you are on an older system you need to update pip, setuptools, and wheel to install newer duplicities.  Not from the repo, but from 'sudo pip install -U ...'.

or in a venv

> It appears that we hit a boundary in 2022 where the new packaging is needed and the packaging in older versions matches older packaging.
>
> Going forward with backwards packaging for older, repo-only, systems is very problematic.  It's all a matrix of which packaging version you have and which duplicity.  In your case you may need to install older packaging to get older duplicities to install.  Gets confusing in a hurry.

yeah, no. setuptools seems to be written off obviously. still i feel we must miss an obvious way to install it as an application with the one binary systemwide or into a specified prefix (e.g. /usr/local/), including all dependencies. can't imagine that all python software is not simply installable by some form of setup anymore.

You mean distutils, not setuptools.  The distutils module has been moved to setuptools._disutils and is used internally

I think the solution is to use pipx.  It creates and manages the activate/deactivate process of the venv it creates.  It's not perfect by a long shot, but it's easier to use than a bare venv.

Regardless, venvs seem the way to go.  I just wish that they had not started this externally-managed-environment nonsense.  It just makes things even more difficult.

...Thanks,
...Ken


 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]