Re^2: Perl6 - Distribution builder/installer

A few responses I already have the answers to:

As well as use implicitly loading the latest version of module where the version is unspecified, and the specified version when requested, the ability to hold debug and/or development versions within the same libtree and request they be loaded would be handy.
According to S11, there are three items that determine what gets loaded:
1. Module name
2. Module version range
3. Module "authorizing authority URI" (usually author).
So, you can have the C6PAN version and the debug version and it will "Just Work".
An tool equivalent to Module::Starter that created a development skeleton in-situ would complete the toolset.
The distro builder would have this action. There's no reason why it should be separated.
Random thought. I wonder if there is any scope/merit in adding svn source control into the mix?
I don't think so. For one thing, SourceForge is still CVS. Another is that some prefer svk over svn and (as I discoverd on feather) they're not identical.
Parrot loading bytecode
This seems to indicate that Parrot is the thing we're installing modules for, not Perl6. So, we would have a module installer for each VM Perl6 targets? We have to reinstall eveyr time Parrot is upgraded? I'm not sure I like that ...
Maybe, instead, we should be looking at caching the bytecode from the module and it's used unless either Perl6 or Parrot or the module has changed? That would seem to be something for "use"/"require" to do ...

In general, if you think something isn't in Perl, try it out, because it usually is. :-)
"What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"

Comment on Re^2: Perl6 - Distribution builder/installer

Replies are listed 'Best First'.
Re^3: Perl6 - Distribution builder/installer by BrowserUk (Patriarch) on May 30, 2005 at 15:34 UTC
So, you can have the C6PAN version and the debug version and it will "Just Work". So, just make the debug version's author 'debug' or similar. Makes sense. I don't think so. For one thing, SourceForge is still CVS. Another is that some prefer svk over svn I guess I should have just said source control (omitting the 'svn'), but most everyone is seems to be settling upon svn recently. It would be kind of nice to have CP6AN be the master repository and then authors could just branch locally for the next version and commit to CP6AN when they're ready. Also, svn/svk will talk to each others repositories won't they? At least for the 'co' & 'up' commands? And the download tool could use the intelligent diffing to update installed packages rather than downloading the whole thing. And just checkout new modules? Not sure if that could work, but the thought crossed my mind so I mention it. I'm not sure where the sourceforge stuff comes in here? Is CP6AN likely to be on SF? This seems to indicate that Parrot is the thing we're installing modules for, not Perl6. I know that Parrot is intended to support multiple languages but I don't recall reading that Perl6 was intending to target multiple VMs? In any case, when the builder runs the test suite, it could (optionally) issue a `perl6 --cache-bytecode -MNew::Module` [download] as a final action if the test passed. Or something... I agree that it is probably a function of use/require to actually load the bytecode, but I thing the Perl6 executable could be asked to load/save/igonore cahced bytecode and the builder module could support thiose options on a case-by-case basis as well as it being a configurable option for an installation? Anyway. Just thoughts for the pot. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.	[reply] [d/l]
Re^4: Perl6 - Distribution builder/installer by dragonchild (Archbishop) on May 30, 2005 at 17:30 UTC
The reason I mentioned sourceforge is that a lot of modules are hosted there, which means that any solution that discusses that type of thing has to take SF into account. SVK, btw, is a wrapper around SVN, so yes they can talk together. As for P6 and multiple VMs - there's no reason why it can't. The P6 compiler will emit PIR, but that doesn't prevent another VM that understands PIR. There's at least three JVMs and two .NET VMs that I know of ... In general, if you think something isn't in Perl, try it out, because it usually is. :-) "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"	[reply]
Re^5: Perl6 - Distribution builder/installer by adrianh (Chancellor) on May 31, 2005 at 10:49 UTC
SVK, btw, is a wrapper around SVN, so yes they can talk together. Not strictly true I'm afraid. SVK uses the Subversion file system, but isn't really compatible with svn clients in all instances. See the SVK FAQ for details.	[reply]