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