Open Stack

On 12/17/2012 04:47 PM, Thomas Goirand wrote:
> On 12/04/2012 09:06 PM, Thierry Carrez wrote:
>> A bit of history here:
>>
>> We used to rely on MANIFEST.in to list all files, but people routinely
>> forgot to add new files to it. Apparently "every Python developer"
>> doesn't know (or care) about this. The end result was that we
>> discovered very late (sometimes after the release itself) that we
>> built incomplete tarballs. As a quick search[1] shows, I have
>> personally filed 27 bugs so far on the subject, so it's not a corner case.
>>
>> [1] http://bit.ly/TDim7U
>>
>> Relying on setuptools_git instead allows to avoid that issue
>> altogether. The projects that adopted it became a non-issue. The
>> projects that didn't adopt it yet are still a problem. I was about to
>> push setuptools_git support to projects that don't use it yet.
>>
>> In summary, I would hate it if we went back to the previous situation.
>> I'm not personally attached to setuptools_git, but any proposed
>> replacement solution should keep its simplicity.
> 
> With my Debian Developer in charge of Openstack, I have to tell that
> this was a real problem for us, in Debian, as well.
> 
> On Debian, we don't use released tarballs like they do on Ubuntu.
JFYI, We at SUSE are in the process to switch to tarballs.opensuse.org.

> [snip]
> 
> The problem isn't to use setuptools_git for building, you're fine to do
> that, the problem is having the Git repositories not holding the correct
> MANIFEST.in file, and fooling the people doing packaging using Git.
That's an important point, and I would like to repeat my previous
statement, if a Python module contains a MANIFEST.in file, it's the
first place a packager would look at. It's distutils, it's standard lib
and what not.

Still, I see the value of setuptools_git for core developers. Their job
of reviewing contributions surely became easier because they don't also
have to track (config) file installation and clean up when other people
just forget.

> This
> means that absolutely all of our packages have to embed a patch in
> debian/patches to "fix" the "wrong" MANIFEST.in.
> 
> We've spent quite some time on that. Or rather, should I say: it's a
> real time waster.
> 
> While I do agree that the MANIFEST.in should be generated automatically,
> I don't think it should be stored in a "wrong" way on github.
So it should either contain something meaningful or be removed. In their
current state, these files are just worthless.

> The magic solution could be to have some automatic tools to take care of
> it. Like, for example, jenkins, or maybe a git hook? I'm not sure, how,
> but I'm quite convince it should be workable.
> 
> Also, we've been having troubles with clean targets accessing the
> network at build time
Yeah, happens here and there. For instance, we patch
sphinx.ext.intersphinx out of every docs/source/conf.py to avoid network
access during doc package build time.

> [snip]
-- 
With kind regards,
Sascha Peilicke
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121218/d49d8850/attachment.sig>