Suggestion: extend App::Perlbrew to do this. Or at least keep a doc section outlining gaps between the two tools.
Steven On Fri, Dec 2, 2011 at 9:56 AM, Phillip Moore <[email protected]> wrote: > So, I'm a little bummed today, because I spent an hour of my time on the > #toolchain IRC channel, trying to get some answers to my CPAN metadata > questions. It was a nearly total waste of time, because I realized we're > solving two entirely different, but cosmetically related problems. > > For example, one of the senior guys (I say that 'cause he's written a lot of > the CPAN-related tools) made the statement that "distribution versions are > meaningless". In my opinion, that's nonsense, because the unit of update > on CPAN is a numerically versionized tarball (or zip file, or whatever). > The dissonance comes from the fact that in EFS, we're solving the GENERIC > problem of how to deploy... versionized releases of software. The > cpan2efs and minicpan code I've written solve that problem pretty well, with > a few edge and corner cases I need to address. The #toolchain folks are > focused almost entirely on MODULE dependencies. > > The other problem is that EFS turns the entire approach to software > deployment upside down. Our hierarchy focuses on the product, then it's > version, and THEN the various compilers and platforms it can be made > available for. The rest of the world (and every single person on > #toolchain) approaches this problem with the opposite hierarchy. You pick a > platform, then you pick a compiler, and then you focus on installing (into > ONE single integrated directory structure) all the products and versions you > need. > > Because of this, tools like cpanp/cpanm/etc can simply start to install one > CPAN distro, and DURING THAT INSTALLATION process, detect dependencies, and > then recursively install them. When you have a SINGLE platform, and a > SINGLE compiler, and a SINGLE directory structure, that's probably the right > way to do it. For the overwhelming majority of perl users and developers, > this is how they build and deploy software. It's not wrong; it's how you > have to do things when you don't have a infrastructure like EFS. > > This approach can NOT be implemented in the current efsdeploy design, which > is nothing more than the result of automating the workflow we've been using > for over 15 years to build products into /efs (or /ms, it's predecessor). > > Still reading? Still wondering what "fakeefs" is? Keep reading :-) > > So, as I'm sure you know, I think there's a tremendous potential for EFS to > be useful to the perl community in general, but sadly noone seems to be able > to build decent NFS infrastructure anymore. (The EFS learning curve, and > the paradigm shift is requires, are too alien to most people, and that's > probably why it's doomed). Well, what if I came up with a way to get > efsdeploy/cpan2efs to work for the single-platform, locally installed > problem space? Well.... THAT is what fakeefs is. > > I looked closely at the nature of the efsdeploy/cpan2efs dependency on efs, > and it's entirely via the CLI and the /efs directory structure. Like I've > always said THAT is the only stable "API" to EFS. Anything that uses the > EFS::* modules, or accesses the efs RDBMS is using interfaces that are > subject to change. > > I'm going to create a very simple, fakeefs project that will include a VERY > simple efs script, that does everything with mkdir. I think I can make it > very easy to setup a fake /efs/dev and /efs/dist so that you can then setup > and use efsdeploy/cpan2efs, although it will be limited to just 2 platforms: > the 32 and 64 bit platforms associated with the local HW. > > Actually, I think "mockefs" is a better name, now that I think about it. > > _______________________________________________ > EFS-dev mailing list > [email protected] > http://mailman.openefs.org/mailman/listinfo/efs-dev > _______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
