> 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:
> 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