<br><br><div class="gmail_quote">On Fri, Jun 22, 2012 at 6:05 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Jun 22, 2012 at 10:01 AM, Donald Stufft <<a href="mailto:donald.stufft@gmail.com">donald.stufft@gmail.com</a>> wrote:<br>
> The idea i'm hoping for is to stop worrying about one implementation over<br>
> another and<br>
> hoping to create a common format that all the tools can agree upon and<br>
> create/install.<br>
<br>
</div>Right, and this is where it encouraged me to see in the Bento docs<br>
that David had cribbed from RPM in this regard (although I don't<br>
believe he has cribbed *enough*).<br>
<br>
A packaging system really needs to cope with two very different levels<br>
of packaging:<br>
1. Source distributions (e.g. SRPMs). To get from this to useful<br>
software requires developer tools.<br>
2. "Binary" distributions (e.g. RPMs). To get from this to useful<br>
software mainly requires a "file copy" utility (well, that and an<br>
archive decompressor).<br>
<br>
An SRPM is *just* a SPEC file and source tarball. That's it. To get<br>
from that to an installed product, you have a bunch of additional<br>
"BuildRequires" dependencies, along with %build and %install scripts<br>
and a %files definition that define what will be packaged up and<br>
included in the binary RPM. The exact nature of the metadata format<br>
doesn't really matter, what matters is that it's a documented standard<br>
that multiple tools can read.<br>
<br>
An RPM includes files that actually get installed on the target<br>
system. An RPM can be arch specific (if they include built binary<br>
bits) or "noarch" if they're platform neutral.<br>
<br>
distutils really only plays at the SRPM level - there is no defined OS<br>
neutral RPM equivalent. That's why I brought up the bdist_simple<br>
discussion earlier in the thread - if we can agree on a standard<br>
bdist_simple format, then we can more cleanly decouple the "build"<br>
step from the "install" step.<br>
<br>
I think one of the key things to learn from the SPEC file format is<br>
the configuration language it used for the various build phases: sh<br>
(technically, any shell on the system, but almost everyone just uses<br>
the default system shell)<br>
<br>
This is why you can integrate whatever build system you like with it:<br>
so long as you can invoke the build from the shell, then you can use<br>
it to make your RPM.<br>
<br>
Now, there's an obvious problem with this: it's completely useless<br>
from a *cross-platform* building point of view. Isn't it a shame<br>
there's no language we could use that would let us invoke build<br>
systems in a cross platform way? Oh, wait...<br>
<br>
So here's some sheer pie-in-the-sky speculation. If people like<br>
elements of this idea enough to run with it, great. If not... oh well:<br>
<br>
- I believe the "egg" term has way too much negative baggage (courtesy<br>
of easy_install), and find the full term Distribution to be too easily<br>
confused with "Linux distribution". However, "Python dist" is<br>
unambiguous (since the more typical abbreviation for an aggregate<br>
distribution is "distro"). Thus, I attempt to systematically refer to<br>
the objects used to distribute Python software from developers to<br>
users as "dists". In practice, this terminology is already used in<br>
many places (distutils, sdist, bdist_msi, bdist_rpm, the .dist-info<br>
format in PEP 376 etc). Thus, Python software is distributed as dists<br>
(either sdists or bdists), which may in turn be converted to distro<br>
packages (e.g. SRPMs and RPMs) for deployment to particular<br>
environments.<br>
<br>
- I reject setup.cfg, as I believe ini-style configuration files are<br>
not appropriate for a metadata format that needs to include file<br>
listings and code fragments<br>
<br>
- I reject <a href="http://bento.info" target="_blank">bento.info</a>, as I think if we accept<br>
yet-another-custom-configuration-file-format into the standard library<br>
instead of just using YAML, we're even crazier than is already<br>
apparent<br></blockquote><div><br></div><div>I agree having yet another format is a bit crazy, and am actually considering changing <a href="http://bento.info">bento.info</a> to be a yaml. I initially did got toward a cabal-like syntax instead for the following reasons:</div>
<div> - lack of conditional (a must IMO, it is even more useful for cross -platform stuff than it is for RPM only)</div><div> - yaml becomes quite a bit verbose for some cases</div><div><br></div><div>I find JSON to be inappropriate because beyond the above issues, it does not support comments, and it is significantly more verbose. That being said, that's just syntax and what matters more is the features we allow:</div>
<div> - I like the idea of categorizing like you did better than how it works in bento, but I think one need to be able to create its own category as well. A category is just a mapping from a name to an install directory (see <a href="http://cournape.github.com/Bento/html/tutorial.html#installed-data-files-datafiles-section">http://cournape.github.com/Bento/html/tutorial.html#installed-data-files-datafiles-section</a>, but we could find another syntax of course).</div>
<div> - I don't find the distinction between source and build very useful in the-yet-to-be-implemented description. Or maybe that's just a naming issue, and it is just the same distinction as extra files vs installed files I made in bento ? See next point</div>
<div> - regarding build, I don't think we want to force people to implement target locations there. I also don't see how you want to make it work for built files (you don't know the name yet). Can you give an example of how it would work for say extension and built doc ?</div>
<div> - regarding hooks: I think it is simpler to have a single file which contains all the hooks, if only to allow for easy communication between hooks and code reuse between hooks. I don't see any drawback to using only one file ?</div>
<div> - Besides containing the file bits + metadata, I wonder if one should allow additional fields, that maybe would be tool specific. In bento, there are a couple of such additional fields that may not be very useful to others.</div>
<div> - do we want to allow for recursive dist.yaml ? This numpy.distutils feature is used quite a bit, and I believe twisted has something similar.</div><div><br></div><div>David</div></div>