setuptools without unexpected downloads

[Paul Boddie]

On 26 Sep, 12:48, "Diez B. Roggisch" <de... at nospam.web.de> wrote:
>

[Quoting me...]

> > However, the argument that a dependency manager cannot deal with
> > different system packages is a weak one: apt and Smart have shown that
> > dependency management can be decoupled from package management.
>
> Do you care to elaborate on how apt has shown that? I use it every day (or
> at least often), but I have to admit I never delved to deeply into them -
> to me it appears that apt is a retrieval-solution, not so much a dependency
> management system. The dependencies are declared in the debs themselves,
> used by dpkg-* - aren't they? Sure, apt does solve them, but how so
> decoupled from the underlying .deps?

Perhaps I was thinking more about the whole apt vs. apt-rpm situation,
since apt-rpm supposedly works with RPMs, albeit in a different
distribution of the software.

> Regarding smart: what I read here
>
> """
> Smart is not meant as an universal wrapper around different package formats.
> It does support RPM, DEB and Slackware packages on a single system, but
> won't permit relationships among different package managers. While
> cross-packaging system dependencies could be enabled easily, the packaging
> policies simply do not exist today.
> This is not at all different from what you can already do. In fact, Debian
> has been shipping the RPM package manager for a few years now. "Possible"
> does not equal "good idea", and everybody should stick to their native
> package format.
> """
>
> in the FAQ doesn't make me think that it's just a matter of unwillingness
> from the setuptools-people but instead an intrinsic property of
> dependency-handling that makes cross-package-management-management (or
> meta-management) hard.

I think the argument is that you use your own system's package format,
but smart is supposed to resolve the dependencies expressed in the
packages itself. There are also universal package formats, but I think
these usually leave some people disappointed, partly because you then
have to consider all the different dependency representations and the
inevitable integration with genuine system packages. I guess this is
why dependency issues were left underspecified in the PEP.

> Apart from the technical intricacies of .deb/.rpm and their respective
> tools, on thing sure makes this an argument: THEY evolve as they like, and
> it sure puts a lot of additional burden to the setuptools-guys to keep
> track with that.

I think most of the evolution has been in the surrounding tools,
although stuff like the new Debian Python policy could be complicating
factors. But I don't think the dependency stuff has changed that much
over the years.

[...]

> >> For example - what if there is no debian package that provides module XY
> >> in the required version? Do you rather install it into the global
> >> site-packages, or do you rather keep it private to the program requiring
> >> it? I'd say the latter is better in mostly all circumstances, as it will
> >> not disrupt the workings of other programs/modules.

[http://www.boddie.org.uk/paul/userinstall.html]

> Certainly a nice solution to a real problem that might be handy for me at
> some time. Yet I fail to see how that relates to the above question: if the
> OS package repository fails to meet a certain version requirement, how do
> you deal with that - installation local to the product you're actually
> interested in installing, or in a more public way that possibly interferes
> with other software?

My response here was mostly addressing the "global site-packages"
issue since that's usually a big reason for people abandoning the
system package/dependency management. If you can't find a new-enough
system package, you have to either choose a local "from source"
installation (which I would regard as a temporary measure for reasons
given elsewhere with respect to maintenance), or to choose to
repackage the upstream code and then install it through the system
package manager, which I claim can be achieved in a non-global
fashion.

Paul