Whoops. that should be:

On Mon, May 26, 2008 at 12:58:45PM -0400, Paul Winkler wrote:
> Oh, and the frozen revision of oc_js was old: it lacked the
> unsaved-changes xinha feature. Fixed in r

... fixed in r17309

- PW


-- 

Paul Winkler
http://www.openplans.org/people/slinkp/profile
yahoo: slinkp23
AIM:   slinkp1970

On Mon, May 26, 2008 at 12:58 PM, Paul Winkler <pw@...> wrote:
> Oh, and the frozen revision of oc_js was old: it lacked the
> unsaved-changes xinha feature. Fixed in r
>
> This raises another objection:
>
> * package A trunk often closely tracks package B trunk.  for example,
>  opencore trunk typically works best with up-to-date trunk checkouts
>  of oc-js, oc-geotagging, et al.

But why does it need to closely track package B trunk?  Maybe I'm
trying too hard to advocate for theoretical ideals, but when oc_js
gained the unsaved-changes xinha feature it should have clearly
declared that with a version change and some sort of stable code
branch with only that change, and opencore trunk's setup.py or the
trunk of the openplans requirements file could more clearly choose
whether to install that version.

If rapid development of our dependencies is happening on trunk without
any broadcasting of what changes are happening, we're just taking on a
lot of overhead and risking random breakage without any clear gain.

> So I think maybe "freeze absolutely everything" is a good approach for
> production deployments, but not for the development trunk.

IMO "freezing" isn't really a _good_ approach anywhere; it's just a
convenience for when we don't have proper fixed releases to peg to.
But unconditionally tracking the trunk of anything seems like a much
worse idea.

Remember that the requirements files plus fassembler essentially
describe, more or less completely, a particular state of the openplans
software stack.  Not to hijack this thread, but, given that, I'm
actually not sure I understand the purpose of the trunk of the
requirements profiles...

> I'm tempted to just revert
> https://svn.openplans.org/svn/build/requirements/openplans/trunk/opencore-req.txt
> to -r17235, but I'll wait to see what the concensus is on tuesday.

A very, very strong +1 on this, especially given that it broke the
build.  I'd much rather we carefully pick what releases, tags and
revisions to freeze to rather than trying to fix a set of requirements
to the point where the build passes.

>> * we could end up with build cruft like so:
>>
>>   - we depend on package A
>>
>>   - package A depends on package B
>>
>>   - package B depends on package C
>>
>>   - we freeze packages A, B, and C into our requirements

Well, there's no reason for us to freeze B and C into our
requirements.  After all, we don't _need_ to freeze everything we use.
 And presumably if A needs B then it's A's job, not "our" job as
consumers of A, to declare B as a requirement somehow.

At worst, I can imagine a situation where [picking completely random
real software packages because it's easier to understand that way] an
external dependency Wicked tracks another external dependency lxml's
trunk; lxml's trunk changes out from under Wicked and breaks it; and
because we don't have any control over Wicked (we can't just peg
Wicked's dependency on lxml) and want to continue to pull in benefits
from Wicked's bugfix and minor releases, we "override" Wicked's lxml
requirement in our requirements files with a known good version of
lxml -- *only until the point at which lxml get fixed, Wicked gets
updated to talk to lxml correctly, or Wicked pegs to another version
of lxml that works for it* -- and then at that point we remove our
"lxml requirement override".  (And even in these situations, it's
often quite likely that we can just talk to the people who _do_ have
control and get the problem fixed at the core.  So I'm really only
talking about something like a day- or week-long emergency expedience
measure.)

Anyway ... is this actually something we're presently doing?

>>   - package A drops the dependency on package B
>>
>>   - we keep installing packages B and C forever, for no reason

Well, or until someone notices.  :P  Doesn't seem like a deal-breaker
to me, though, again, I also am not sure when and where this scenario
actually occurs in real life.

egj

On Tue, May 27, 2008 at 12:23 PM, Ian Bicking <ianb@...> wrote:

> Paul Winkler wrote:
>
>> I'm having second thoughts about this approach:
>>
>> * it broke the build, since several requirements could not be
>>  installed as written by poach-eggs.  See r17307 for a quick fix.
>>
>
> These are basically some kind of bug.  I don't know why we didn't notice
> collective.testing, which clearly needed something done (and maybe we need a
> firmer warning about it).  Robert had some plone.mail problems that we
> couldn't reproduce when we tried to install from the req file. I don't know
> was wrong with the plone.memoize requirement.
>
>  * we could end up with build cruft like so:
>>
>>  - we depend on package A
>>
>>  - package A depends on package B
>>
>>  - package B depends on package C
>>
>>  - we freeze packages A, B, and C into our requirements
>>
>>  - package A drops the dependency on package B
>>
>>  - we keep installing packages B and C forever, for no reason
>>
>
> I didn't realize we were freezing the trunk.  I agree (for this reason and
> some others Ethan notes) that it doesn't seem like a good idea to me.  I
> would envision freezing in two cases.  One is a release, where you freeze
> the release as it was actually made, both informationally and in case anyone
> wants to start work from that release (e.g., to make a bug fix) then they'll
> be able to recreate a development stack that represents the release.
>
> The second case is a release branch, where we want to decrease the number
> of moving parts.  In that case, we'd freeze on the branch and then relax
> requirements as necessary.  I.e., unless someone explicitly chooses to
> develop a piece of the stack, make sure the piece doesn't change.  You'd
> relax requirements manually by editing the file.
>
> Freezing without a commit could also be a tool for just inspecting the
> state of our requirements.  For example, it could let you detect products
> that aren't tagged or properly released, but should be.
>
> I don't think we can release everything we want to use, though we could do
> better than we do now.  I think if we tried that we'd be running around
> releasing things we weren't even sure worked right, because the release
> schedule of the site and the products just don't sync (not often now, and
> still not always even in some better future).
>
> We definitely can't put this information into setup.py.  I feel setup.py is
> only appropriate for specifying known conflicts.  That is, you can put in a
> minimum version of a requirement if you know it has a bug you need fixed.
>  Otherwise the requirements in setup.py should be sufficiently vague that we
> can install libraries in different combinations, and test and release the
> combination instead of just the individual libraries.
>
>  Ian
>

I didn't mean to check that into openplans/trunk, but rather into something
like livablestreets/releases/woonerf_week2. Sorry about that. Never commit
anything right before leaving after Friday night happy hour!

Anyway, before we actually can use a poach-eggs--generated requirements
file, let's look into what caused the oc-js, oc-geotagging, plone.mail,
plone.memoize, and collective.testing requirements to be written wrong.

Attachments

text.html (text/html) 3.9 kB