On Jul 17, 2013, at 3:58 PM, zooko <zo...@zooko.com> wrote: > In my opinion it is a good idea to embed, not just the *name* of the package > that your package depends on, but also the public key or public keys that your > package requires the depended-upon package to be signed by.
The problem with this is it makes it more difficult to replace a library with a
patched copy.
Example:
I want to install the library Foo, Foo depends on Bar, and Bar depends
on Broken. Broken
is well, broken and I want to use a patched version of it locally. So I
fix Broken, upload
it to my private index server and I pip install from that.
If public keys are encoded as part of the dependency chain, not only do
I need to patch Broken
but I also need to patch Foo and Bar _and_ anything else that depends
on Foo, Bar, or Broken
_and_ anything else that depends on those, so on until we reach the
leaves.
Packages should have signatures. Dependency should be by name. End tooling
should provide a method to make a set of requirements with certain signatures
or hashes for a specific instance of this installation. (E.g. Awesome, Inc
could have a set of requirements that contain Foo, Bar and their own patched
version of Broken along with the keys used to sign all of them).
-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
