I don't think dependency information can go in setup.py files. Dependency information grows over time, and can be complex; e.g., version 1.0 of X works, but for some feature you need version 1.1. What do you depend on then? You can fiddle around with extras, but it's all very awkward, and easy_install doesn't handle it very elegantly anyway. And you just can't know what the dependencies really are; there will be new versions of packages and you can't know whether those new versions will or won't be compatible. Pre-declaring them incompatible isn't good, but if you don't keep your versions pinned down you can't be sure that you won't break something. And editing setup.py everytime you learn something new is not feasible either. Do you re-release each time? Blech.
This is why I think we need a formal notion of a set of packages that work together, separate from any single package. I think .NET has some notion of external dependency information that you can add to a package, and maybe that offers something interesting to consider (or maybe not). I've been pretty happy with the requirement file, a simple list of packages. It's also easy to maintain, copy, and version. A package index seems way too heavy in comparison. I suppose you could run an index off such a file, but why bother? We also have a script to take a working set of packages and create a requirement file that specifies exact versions of every package, complete with svn version pins when there isn't a proper tag; the known-good issue. I think buildout config files basically have the same effect.
The problem is....
Posted byzopyxat
2008-03-10 01:31 AM
dependency conflict..with huge bag of packages and dependencies you will likely run into dependency conflict where package A requires version X of package C where package B requires version Y of package C...This is very hard to resolve..basically the build system (easy_install, buildout or whatever) can only fail in such a case.
1205420630
Posted bytseaverat
2008-03-13 11:03 AM
Ian wrote:
> Pre-declaring [new versions] incompatible isn't good, but if you don't keep
> your versions pinned down you can't be sure that you won't break something.
> And editing setup.py everytime you learn something new is not feasible
> either. Do you re-release each time? Blech.
Agreed: you need to leave the setup.py of dependent packages somewhat relaxed.
> This is why I think we need a formal notion of a set of packages that work together,
> separate from any single package.
What we've been calling the "known-good set" (KGS) on the zope-dev list.
The way we have chosen to model the KGS is to make a separate, controlled
package index (a "gated community") which filters package updates from
the "wild West" of the cheeseshop.
> I think .NET has some notion of external dependency information that
> you can add to a package, and maybe that offers something interesting
> to consider (or maybe not). I've been pretty happy with the requirement
> file, a simple list of packages. It's also easy to maintain, copy, and
> version. A package index seems way too heavy in comparison. I suppose
> you could run an index off such a file, but why bother?
Keeping a "local package cache" for you project isolates you from
flakiness on other indexes (network, server stability, etc.) Making
a package index from a working set is a pretty trival exercise: check
out the last example on the compoze README:
This is why I think we need a formal notion of a set of packages that work together, separate from any single package. I think .NET has some notion of external dependency information that you can add to a package, and maybe that offers something interesting to consider (or maybe not). I've been pretty happy with the requirement file, a simple list of packages. It's also easy to maintain, copy, and version. A package index seems way too heavy in comparison. I suppose you could run an index off such a file, but why bother? We also have a script to take a working set of packages and create a requirement file that specifies exact versions of every package, complete with svn version pins when there isn't a proper tag; the known-good issue. I think buildout config files basically have the same effect.
> Pre-declaring [new versions] incompatible isn't good, but if you don't keep
> your versions pinned down you can't be sure that you won't break something.
> And editing setup.py everytime you learn something new is not feasible
> either. Do you re-release each time? Blech.
Agreed: you need to leave the setup.py of dependent packages somewhat relaxed.
> This is why I think we need a formal notion of a set of packages that work together,
> separate from any single package.
What we've been calling the "known-good set" (KGS) on the zope-dev list.
The way we have chosen to model the KGS is to make a separate, controlled
package index (a "gated community") which filters package updates from
the "wild West" of the cheeseshop.
> I think .NET has some notion of external dependency information that
> you can add to a package, and maybe that offers something interesting
> to consider (or maybe not). I've been pretty happy with the requirement
> file, a simple list of packages. It's also easy to maintain, copy, and
> version. A package index seems way too heavy in comparison. I suppose
> you could run an index off such a file, but why bother?
Keeping a "local package cache" for you project isolates you from
flakiness on other indexes (network, server stability, etc.) Making
a package index from a working set is a pretty trival exercise: check
out the last example on the compoze README:
http://svn.repoze.org/compoze/trunk/README.txt