tahoe-lafs/trac-2024-07-25

how does a packager find version requirements for indirect dependencies? #1343

New issue

Open

opened 2011-01-29 03:59:46 +00:00 by davidsarah · 4 comments

davidsarah commented

2011-01-29 03:59:46 +00:00

Owner

The method of finding Tahoe's indirect requirements documented at http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AdvancedInstall#Dependencies,

requires a built copy of Tahoe, and
only prints the versions being used by that copy, not the requirements.

The indirect dependencies are pyutil, zbase32, and argparse. It might be easier just to document that (with minimum version requirements if any) and update the documentation manually.

The method of finding Tahoe's indirect requirements documented at <http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AdvancedInstall#Dependencies>, * requires a built copy of Tahoe, and * only prints the versions being used by that copy, not the requirements. The indirect dependencies are pyutil, zbase32, and argparse. It might be easier just to document that (with minimum version requirements if any) and update the documentation manually.

tahoe-lafs added the

labels 2011-01-29 03:59:46 +00:00

tahoe-lafs added this to the undecided milestone 2011-01-29 03:59:46 +00:00

dstufft commented

2013-10-10 19:53:55 +00:00

Author

Owner

For instance:

tahoe-lafs depends on foo, foo 1.0 depends on bar, foo 2.0 depends on wat

In the above example there isn't a single set of requirements, it's a tree where the final set depends on what version of foo ends up being selected for installation. It can be expressed of course but it can be a very confusing representation if the version specifiers of anything but the root of the tree varies. If they are static then you can collapse the branches into a single branch and you may (in a simple case) get a single set because every combination of dependencies ends up having the same requirement specifiers.

This is actually a pretty hard problem to solve. The issue is that indirect dependencies are not a concrete thing and can depend on what version of direct dependencies get installed (or are already installed). For instance: ``` tahoe-lafs depends on foo, foo 1.0 depends on bar, foo 2.0 depends on wat ``` In the above example there isn't a single set of requirements, it's a tree where the final set depends on what version of foo ends up being selected for installation. It *can* be expressed of course but it can be a very confusing representation if the version specifiers of anything but the root of the tree varies. If they are static then you can collapse the branches into a single branch and you may (in a simple case) get a single set because every combination of dependencies ends up having the same requirement specifiers.

daira commented

2013-10-17 15:01:57 +00:00

Author

Owner

I'd really prefer to just remove the dependencies on pyutil, zbase32, and argparse (or promote them to direct dependencies if Tahoe really transitively needs them).

exarkun commented

2020-01-16 20:20:16 +00:00

Author

Owner

Tahoe-LAFS has a lot of transitive dependencies now. If anything, this issue is much worse and more pressing than it was 7 years ago. Yet there is still no particularly good solution.

"Try some versions and see if they work"? That is essentially all the Tahoe-LAFS project does. "some versions" are generally "the latest releases of most things at the time of testing / release".

A package could look at Tahoe-LAFS CI and see what those versions are and pick them. On the other hand, a packager is almost certainly going to use whatever versions of the dependencies someone else has already packaged in the system they are packaging for. And if the result doesn't work ... well, is anyone going to care?

I think it would be great to fix this but I don't know what change is actually going to be helpful, nor to whom. It would probably be better if some packagers showed up and asked for something that would help them out. That tends not to happen, though. Packagers are busy and often don't spend a lot of time proactively engaging with upstream.

Maybe no one should use a Tahoe-LAFS packaged by anyone except the Tahoe-LAFS project. That would simplify matters significantly.

Tahoe-LAFS has a lot of transitive dependencies now. If anything, this issue is much worse and more pressing than it was 7 years ago. Yet there is still no particularly good solution. "Try some versions and see if they work"? That is essentially all the Tahoe-LAFS project does. "some versions" are generally "the latest releases of most things at the time of testing / release". A package could look at Tahoe-LAFS CI and see what those versions are and pick them. On the other hand, a packager is almost certainly going to use whatever versions of the dependencies someone else has already packaged in the system they are packaging for. And if the result doesn't work ... well, is anyone going to care? I think it would be great to fix this but I don't know what change is actually going to be helpful, nor to whom. It would probably be better if some *packagers* showed up and asked for something that would help them out. That tends not to happen, though. Packagers are busy and often don't spend a lot of time proactively engaging with upstream. Maybe no one should use a Tahoe-LAFS packaged by anyone except the Tahoe-LAFS project. That would simplify matters significantly.

exarkun commented

2020-01-16 20:37:10 +00:00

Author

Owner

This seems awfully closely related to https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1452

This seems awfully closely related to <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1452>