Merge lp:~jtv/maas/quantal-updates into lp:maas/trunk
| Status: | Rejected |
|---|---|
| Rejected by: | Jeroen T. Vermeulen on 2012-09-21 |
| Proposed branch: | lp:~jtv/maas/quantal-updates |
| Merge into: | lp:maas/trunk |
| Diff against target: |
21 lines (+2/-2) 1 file modified
versions.cfg (+2/-2) |
| To merge this branch: | bzr merge lp:~jtv/maas/quantal-updates |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| John A Meinel | Approve on 2012-09-21 | ||
| Julian Edwards (community) | 2012-09-21 | Approve on 2012-09-21 | |
|
Review via email:
|
|||
Commit Message
Bump lxml and bzr versions; they're too old to be available in quantal.
Gets “make” working in Quantal. Tests still pass in Precise. The bzr version sounds as if it may still go through a further upgrade.
Description of the Change
See commit message. As mentioned on mailing list.
Jeroen
| John A Meinel (jameinel) wrote : | # |
I think:
a) We can't just remove the bzr line (osutils.
b) for lxml... whatever works. :) I'm fine with a >= or a hard coded value.
| Julian Edwards (julian-edwards) wrote : | # |
On Friday 21 September 2012 06:10:39 you wrote:
> Review: Approve
>
> I think:
>
> a) We can't just remove the bzr line (osutils.
> However, I don't think we have to use that. There is only 1 use of bzrlib,
> and it is a small bit of code.
I'd rather pull bzrlib from packaging than download a copy from pypi. In fact
I'd like to start pulling most of our deps from packaging, it'll give us fewer
surprises via version skew in the long run.
> b) for lxml... whatever works. :) I'm fine with a >= or a hard coded value.
Sadly it won't work with a >= it seems, we have
allow-picked-
in buildout.cfg :( I can't remember why either.
| Gavin Panella (allenap) wrote : | # |
On 21 September 2012 08:25, Julian Edwards <email address hidden> wrote:
...
> I'd rather pull bzrlib from packaging than download a copy from pypi. In fact
> I'd like to start pulling most of our deps from packaging, it'll give us fewer
> surprises via version skew in the long run.
I think the rule should be something like: all dependencies that will
be used by packaged code should also come from packages, but test-only
dependencies can come from PyPI too (or elsewhere).
>> b) for lxml... whatever works. :) I'm fine with a >= or a hard coded value.
>
> Sadly it won't work with a >= it seems, we have
>
> allow-picked-
>
> in buildout.cfg :( I can't remember why either.
I think this is so buildout doesn't pick random new versions of
packages, causing us to chase our tails fixing things. We could
experiment with disabling this, but I suspect it'll get frustrating.
We may have to have separate versions.cfg for Precise and Quantal, but
I'm not entirely sure how we can hook that in elegantly.
| Julian Edwards (julian-edwards) wrote : | # |
On Friday 21 September 2012 08:37:18 you wrote:
> On 21 September 2012 08:25, Julian Edwards <email address hidden>
> wrote: ...
>
> > I'd rather pull bzrlib from packaging than download a copy from pypi. In
> > fact I'd like to start pulling most of our deps from packaging, it'll
> > give us fewer surprises via version skew in the long run.
>
> I think the rule should be something like: all dependencies that will
> be used by packaged code should also come from packages, but test-only
> dependencies can come from PyPI too (or elsewhere).
+1
> >> b) for lxml... whatever works. :) I'm fine with a >= or a hard coded
> >> value.
> >
> > Sadly it won't work with a >= it seems, we have
> >
> > allow-picked-
> >
> > in buildout.cfg :( I can't remember why either.
>
> I think this is so buildout doesn't pick random new versions of
> packages, causing us to chase our tails fixing things. We could
> experiment with disabling this, but I suspect it'll get frustrating.
> We may have to have separate versions.cfg for Precise and Quantal, but
> I'm not entirely sure how we can hook that in elegantly.
Makes sense. However we've got the same problem in reverse where the dev
environment is stable but newer packages in quantal bite us randomly in QA
(and worse, production).
We really need to get rid of buildout for non-test packages as you say above.
Also remember we've got different branches for precise vs quantal now, so just
hack versions.cfg as appropriate. Ideally, getting rid of entries and putting
them in required-packages :)
| Gavin Panella (allenap) wrote : | # |
On 21 September 2012 10:17, Julian Edwards <...> wrote:
> Also remember we've got different branches for precise vs quantal
> now, so just hack versions.cfg as appropriate.
D'oh, of course, I forgot about that.
> Ideally, getting rid of entries and putting them in
> required-packages :)
Good point; buildout has include-
use buildout to manage test dependencies, and drop all package
dependencies from its purview.
| Julian Edwards (julian-edwards) wrote : | # |
On Friday 21 September 2012 09:37:24 you wrote:
> > Ideally, getting rid of entries and putting them in
> > required-packages :)
>
> Good point; buildout has include-
> use buildout to manage test dependencies, and drop all package
> dependencies from its purview.
Sounds ideal, I've just filed bug 1055235 about this.
Unmerged revisions
- 1040. By Jeroen T. Vermeulen on 2012-09-21
-
Package updates for Quantal.
As discussed on IRC, I don't think we need bzr any more (and if we do we should use system packages). Also instead of
lxml = 2.3.5
we should have:
lxml >= 2.3.2
Approved with these two changes.