Dependency extensions
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have use cases for a couple of extensions to how requirements are spelled in a setuptools-enabled project. Overriding Requirements - ----------------------- I would like to be able to require package 'bar', but override one or more of its dependencies (typically, 'bar' has over-strict version qualifiers, which I need to relax). I can imagine spelling such an override by including the overridden project with a qualifier, e.g.: in foo/setup.py: install_requires=['bar', '!baz==1.3', #override bar's spec of 1.2.4 ] The "bang" here is borrowed loosely from CSS; other spellings might be clearer. Another spelling might be to pass 'nodeps' or something as a suffix to the overly-strict package, e,g,:: install_requires=['bar (nodeps=baz)', 'baz==1.3', ] In general, I think the principal that the "most dependent" package wins would be a reasonable policy, although not backward compatible at this point. Pinning Download Pages - ---------------------- I would like to be able to "pin" a given package to a particular index / download page, rather than searching the standard locations. I could imagine either supplying the "pinned" find_url as a suffix, e.g.: install_requires=['baz (http://example.com/download-baz-here/)', ] Or else supplying a mapping which is used for the pinned URLs:: install_requires=['baz'], pinned_urls={'baz': 'http://example.com/download-baz-here'} The second might be easier to implement, but feels clunkier. Thoughts? Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHDoKC+gerLs4ltQ4RAqR0AJ99D44ob2Od0WecAW05E+MGcDruOgCgo7zV q7XZxbyhFeh9engIsX0p/Rs= =9bFP -----END PGP SIGNATURE-----
At 04:07 PM 10/11/2007 -0400, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I have use cases for a couple of extensions to how requirements are spelled in a setuptools-enabled project.
You should probably include them, then. You only sent the specifications for how you'd like to implement *solutions* for the problems posed by your use cases. ;-) In other words, you didn't explain why it is you think you know better than the package owner what version his package needs, or why the existing dependency URL features don't do what you want.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Phillip J. Eby wrote:
At 04:07 PM 10/11/2007 -0400, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I have use cases for a couple of extensions to how requirements are spelled in a setuptools-enabled project.
You should probably include them, then. You only sent the specifications for how you'd like to implement *solutions* for the problems posed by your use cases. ;-)
In other words, you didn't explain why it is you think you know better than the package owner what version his package needs, or why the existing dependency URL features don't do what you want.
In the case of overrides, I have seen lots of cases where project authors have overspecified dependencies in their requirements for a given distribution, mostly because they don't want to have to support their package configurations they don't test. I'm fine with that line of thought, as long as I have a way to reuse their packaged stuff in combination with mine, where I *do* test with a different version than they do: in such a case, if my package can signal to setuptools that *my* specification should win, I can use their code without forking a new distribution. Working around such a problem today typically requires hand-editing the 'requires.txt' for the over-strict package after installing it. Setup tools provides no way to install an over-strict package as a dependency without propagating those constraints. Pinning a package to a given repository is a common packaging requirement (yum and apt both support it). The driver there is the need to maintain a "known good" configuration, where some packages (at least) are installed from a repository whose maintainers are more reliable / trustworthy than others. (e.g., some maintainers are pretty sloppy about re-releasing packages "in place", or even removing them). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHDpOY+gerLs4ltQ4RAseJAJ0T16bFz/mLSPIZq95wUsGKBaUeiwCg1Ag2 RA+Q12lRKThc02ZHzy4dG2c= =+0UV -----END PGP SIGNATURE-----
On Oct 11, 2007, at 2:20 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Phillip J. Eby wrote:
At 04:07 PM 10/11/2007 -0400, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I have use cases for a couple of extensions to how requirements are spelled in a setuptools-enabled project.
You should probably include them, then. You only sent the specifications for how you'd like to implement *solutions* for the problems posed by your use cases. ;-)
In other words, you didn't explain why it is you think you know better than the package owner what version his package needs, or why the existing dependency URL features don't do what you want.
In the case of overrides, I have seen lots of cases where project authors have overspecified dependencies in their requirements for a given distribution, mostly because they don't want to have to support their package configurations they don't test. I'm fine with that line of thought, as long as I have a way to reuse their packaged stuff in combination with mine, where I *do* test with a different version than they do
Just because you tested your app against "bar" 1.4 and "baz" 1.3 doesn't mean that every feature of "bar" will work with "baz" 1.3. Another app could break because it uses a feature of "bar" that doesn't work with that version of "baz" and the authors of one of those packages will get the bug report about it instead of you. If you're willing to help with the testing the author might be willing to relax the requirements, but trying to override another package's requirements is likely to lead to problems. -- Matt http://five.sentenc.es
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Good wrote:
On Oct 11, 2007, at 2:20 PM, Tres Seaver wrote:
authors have overspecified dependencies in their requirements for a given distribution, mostly because they don't want to have to support their package configurations they don't test. I'm fine with that line of thought, as long as I have a way to reuse their packaged stuff in combination with mine, where I *do* test with a different version than they do
Just because you tested your app against "bar" 1.4 and "baz" 1.3 doesn't mean that every feature of "bar" will work with "baz" 1.3. Another app could break because it uses a feature of "bar" that doesn't work with that version of "baz" and the authors of one of those packages will get the bug report about it instead of you. If you're willing to help with the testing the author might be willing to relax the requirements, but trying to override another package's requirements is likely to lead to problems.
I agree that this might be problematic in a setup where different applications share the 'site-packages' directory. Conflicts of this sort drove the development of "virtual_python" / "virtualenv" setups, which make it trivial to isolate separate applications' package sets. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHFeeH+gerLs4ltQ4RAl4UAKDDZy32Tl2SWcdqzzP8U+QyWuKaAgCg0DuS BoetwylWptg1HmAdcxGL8lo= =Ys+B -----END PGP SIGNATURE-----
At 06:44 AM 10/17/2007 -0400, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matt Good wrote:
On Oct 11, 2007, at 2:20 PM, Tres Seaver wrote:
authors have overspecified dependencies in their requirements for a given distribution, mostly because they don't want to have to support their package configurations they don't test. I'm fine with that line of thought, as long as I have a way to reuse their packaged stuff in combination with mine, where I *do* test with a different version than they do
Just because you tested your app against "bar" 1.4 and "baz" 1.3 doesn't mean that every feature of "bar" will work with "baz" 1.3. Another app could break because it uses a feature of "bar" that doesn't work with that version of "baz" and the authors of one of those packages will get the bug report about it instead of you. If you're willing to help with the testing the author might be willing to relax the requirements, but trying to override another package's requirements is likely to lead to problems.
I agree that this might be problematic in a setup where different applications share the 'site-packages' directory. Conflicts of this sort drove the development of "virtual_python" / "virtualenv" setups, which make it trivial to isolate separate applications' package sets.
Then perhaps such overrides should be used mainly for virtual environments, where you can prioritize *whose* requirements should take precedence. That is, if you are installing 'foo' into a virtualenv intended only for the running of 'foo', then it might be reasonable for its requirements to take precedence. However, ISTM that the "right" solution (for some value of "right") is that packagers who wish to overspecify their dependencies should create virtual packages for that purpose, rather than baking fixed-version requirements into the base package.
participants (3)
-
Matt Good -
Phillip J. Eby -
Tres Seaver