setuptools without unexpected downloads

Diez B. Roggisch deets at nospam.web.de
Wed Sep 26 05:16:11 EDT 2007


Ben Finney wrote:

> "Diez B. Roggisch" <deets at nospam.web.de> writes:
> 
>> Ben Finney schrieb:
>> > To clarify: I want to retain the "assert the specified
>> > dependencies are satisfied" behaviour, without the "... and, if
>> > not, download and install them the Setuptools Way" behaviour.
>> >
>> > Instead, I just want the default "dependencies not satisfied"
>> > behaviour for my 'setup.py' program to be: complain the
>> > dependencies aren't met, and refuse to install.
>> 
>> The problem here is that your favorite OS vendor/distributor not
>> necessarily offers the required meta-information - so setuptools
>> can't check the dependencies.
> 
> Let's assume it does. How would I modify my 'setup.py' script so that
> its default behaviour, when dependencies are not met, is not "download
> and install dependencies via setuptools" but instead "exit with error
> message"?

easy_install has the --no-deps commandline argument. I'm not sure if that is
triggerable from inside setup.py - but in the end, you wanted user choice,
didn't you?

Generally speaking, I think the real problem here is the clash
between "cultures" of dependency-handling. But it's certainly beyond
setuptools scope to cope with every imaginable package management system
out there, and provide means to trigger an installation of say e.g. debian
packages that are needed.

So - if you really want to go the debian/ubuntu/suse/whatever-way, provide
packages in their respective format, with the dependencies met.

If you are not willing to do that, the self-contained solution at least
offers an option for hassle-free first time installation, especially when
there is a mixture of meetable and non-meetable dependencies with the OS
system.

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.

Diez



More information about the Python-list mailing list