efs and perlbrew have entirely different approaches to how to manage the namespace. I don't think it makes much sense, and I'm not going down this road for now.
The goal is to simulate EFS, and mimic the CLI and the namespace. The perlbrew CLI and namespace have NOTHING in common with EFS, so I don't see the point. But hey, someone else is welcome to try..... On Fri, Dec 2, 2011 at 11:11 AM, Steven Jenkins <[email protected]>wrote: > 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 >
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
