launchpad-reviewers team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxx>]

On 12-02-28 08:39 AM, Gavin Panella wrote:
> Review: Approve
> 
>> Thanks for the review, I've fixed everything you asked for.
> 
> I'm very sorry I didn't reply yesterday; I had forgotten I marked it
> Needs Fixing (and I obviously can't read email).
> 
>>> [6]
>>>
>>> +download-cache = download-cache
>>>
>>> /^download-cache/d
>>>
>>> We've chosen to *not* define this in <branch>/buildout.cfg; we're
>>> using ~/.buildout/default.cfg to use a shared cache. This is much
>>> easier than following the Launchpad model while MaaS's deps are small
>>> enough.
>>
>> Well, ok. But I disagree, it's not easier than the Launchpad model if
>> you have a lot of different projects managed by buildout. In which case,
>> you end up with a massive eggs and download-cache where it's very hard
>> to know what comes from where.
> 
> I agree with having a separate download-cache and eggs directory when
> deploying from a tree built using buildout, like Launchpad. Then you
> can't go and nuke the shared caches because you'll break things. But
> for MaaS, buildout is only for development, so using a shared cache -
> so that all branches build quickly without having to think about it -
> is a win.

Right, I'm all for using a shared cache, and I symlink download-cache to
that shared cache. My beef is just that if the way you set your shared
cache is ~/.buildout/defaults.cfg then that's shared cache is actually
used for all of your buildout-managed development projects (which don't
override it locally). And that's what I personally don't like. But like
I said, it's more a personal preferences than anything else.


> 
>>> [12]
> ...
>> I've reordered the file versions.cfg file as you suggested, but I'm not
>> sure that generating the setup.py dependency from versions.cfg is such a
>> good idea. This will basically mean that the version will be pinned like
>> in buildout, which is good for repeatable builds, but not so much for
>> general use. Given that we are not going to release that package on
>> PyPI, maybe that's kind of moot (and mean that setup.py isn't that
>> interesting either).
> 
> Why no release on PyPI?
> 

Well, that's not a binding decision. We could upload it to PyPI I guess,
but given that this is more an application than a library and that it's
targeted at deployment in Ubuntu... why bother?

> Looks good to go, +1.
> 

Thanks!

-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx


https://code.launchpad.net/~flacoste/maas/buildout-site-packages/+merge/94628
Your team Launchpad code reviewers is requested to review the proposed merge of lp:~flacoste/maas/buildout-site-packages into lp:maas.