Coffee is still kicking in -- forgot to Reply-All and share this with the list.....
---------- Forwarded message ---------- From: Phillip Moore <w.phillip.mo...@gmail.com> Date: Sat, Jun 2, 2012 at 11:35 AM Subject: Re: Issues with VERSION migration in a module suite To: Elliot Shank <p...@galumph.com> I disagree -- you have to deal with both dependencies on modules and distributions. Both types of dependency serve slightly different purposes. For example, internally in perl you will specify a dependency on a specific version of a specific module: use Foo::Bar 1.0; But, when Foo::Bar is part of a *suite* of modules, which you can't install independent of the distribution, then you have to think about depending on the distribution, perhaps Foo-2.1.tar.gz. I came at this problem from a very, very different angle. I have developed a very large scale system for managing arbitrary releases of software in a common, versionized namespace, and developed a set of configurable tools for automating the entire installation and deployment process. That software is agnostic with respect to the language or build system used to install the distribution in question, and I factored out a common framework for doing this. I have support for GNU configure, perl's build systems (Build.PL and Makefile.PL), python and ruby packages, etc. This system specifies it's dependencies on the distributions, because it's the distribution that is quantum of a software release. IOW, you don't install modules, you install distributions. The same is true for things like C dependencies. GNU gcc depends libgmp and libmpfr, but in order to automate the installation process, I need to know that it depends on gmp-x.y.z.tar.gz and mpfr-a.b.x.tar.gz. Furthermore, CPAN dependencies are specified at the distribution level. META.yml (and it's variants) are all distribution specific files, however the dependencies they specify are on individual modules. To integrate perl with my infrastructure I convert the module dependencies into a set of distribution dependencies, and then automate the installation (and the *really* hard and fun part: runtime dependence management) into my namespace. The point is that the two different kinds of dependencies serve very different purposes. I need to know what distributions something depends on in order to install them, since the installation process is per-distribution, but I need to know what modules I depend on, and perhaps what minimal version I need, in order to manage API dependencies. To say we need one or the other misses this fact -- you need both. Now, it sure would be nice if people could standardize on the convention that ALL of the modules in a given distribution share the same version number, but we can't even get people to upload META.yml/json files consistently. One of the things I have to do to make my system work is post-process the minicpan updates and make sure that I have a metadata file for ALL of the distros possible. I don't have recent statistics (I should really log this...) but last time I did a cursory check a few months ago, nobly about 90-95% of the modules being uploaded included a metadata file. With the trend to depend on MYMETA files, which are unfortunately only generated during the build process and are not available in the downloaded tar ball, this percentage may very well decrease. THAT point being: if you are developing a system to manage arbitrary CPAN modules, you can't depend on people following *any* guidelines, and you have to take a heuristic approach and handle a lot of ugly edge conditions. On Fri, Jun 1, 2012 at 11:03 PM, Elliot Shank <p...@galumph.com> wrote: > On 6/1/12 9:49 PM, David E. Wheeler wrote: >> >> On Jun 1, 2012, at 2:39 PM, Steffen Schwigon wrote: >>>> >>>> In that vein, I would like to know: do you, as someone who has spent >>>> time in the trenches working with packaging, believe that version >>>> numbers and dependencies are best expressed at the distro level or at >>>> the package/module level? >>> >>> >>> It will be a different answer for each CPAN author >>> and in Perl this individualism is our collectivism. >> >> >> No it won’t, and no it isn’t. > > > I agree with Mr. Wheeler. > > As someone who's split modules out of a distribution before and someone > who's dealing with Ruby gems a lot currently, I'd say that the > dependency-on-a-distro model is broken. Perl's dependency-on-a-module model > is the correct one. When the contents of a distro change, > dependency-on-a-module continues to work, whereas a dependency-on-a-distro > does not.
