changing default perl

[Ryan Schmidt]

On Nov 11, 2013, at 10:44, Daniel J. Luke wrote:

> On Nov 11, 2013, at 11:32 AM, Ryan Schmidt wrote:
>> 
>>> It would certainly be possible to have some local metadata that our cpanm could consult to do any of the above, though.
>> 
>> This sounds like inventing a second language to do what we can already do in portfiles.
> 
> I guess it could be implemented that way, but it's not really what I was thinking.

What were you thinking of?


>> I like Jeremy’s idea of adding a portfile only if necessary to fix issues (add patches, etc.).
> 
> that would probably work.
> 
>>> The main benefit would be that /all/ of the modules would be available in a MacPorts supported way and they would be up-to-date without an army of volunteers building cookie-cutter portfiles for them.
>> 
>> And that would be great!
>> 
>> If we do this, we should find a way to make it abstract so that we can integrate other package managers besides CPAN. For example we have the same problem for php’s PEAR package manager: two years ago, Bradley put all of PEAR in MacPorts, but it hasn’t been updated since then. Perhaps this functionality could still be implemented as portgroups, or at least as tcl files in the _resources directory, so that new MacPorts base releases are not needed to make changes there.
> 
> I don't really know how other languages do this (and I'm no php expert). I'm at least somewhat leery of trying to design the most generic solution for this too (I would much rather make something that works and extend it if it seems reasonable to do so).
> 
> I think we require base/ changes if only because there won't necessarily be a portfile for each perl module yet there are going to be ports that depend on some of these modules (so we would need a way to handle that).

Yes, base would need to be changed to accommodate this new feature. But I see it as a minimal shim onto calling this other package manager.

Thinking off the top of my head…

We invent a new dependency type, let’s say “module”. Other ports would depend on e.g. CPAN’s Archive::Tar module with “depends_lib module:cpan:Archive::Tar”. MacPorts base would be enhanced to know that “module” dependencies are handled without separate portfiles, by a “portgroup” in _resources. Maybe it’s not called a portgroup; maybe it lives in _resources/port1.0/modules instead. Whatever we call it, this cpan-1.0.tcl file knows what binary to call, what ports to depend on to install that binary, how to call the binary to install or uninstall the requested module, determine its license, etc.

Generally, to install or uninstall a PERL CPAN module, you use the “cpan” command with some arguments. Similarly, to install or uninstall a PHP PEAR module, you use the “pear” command with some arguments. There are compiled PHP modules installed with “pecl”. There are Ruby modules installed with “gem”. There are node modules installed with “npm”. etc etc etc. Whoever modifies base to add this feature doesn’t need to know more than that; the individual Tcl files in the modules folder would handle the specifics.


> also - having to create releases to add functionality really shouldn't be something that we try to hack around by pushing code some other way. Does our release process need some attention to make it easier to do?

Compare:

Editing one file in the _resources directory

With:

Editing one file in base somewhere, updating the changelog for this and all other changes made to base since the last release because people forget to update the changelog, making sure no untested fixes have been committed since the last release, making a source tarball, firing up six different OS X versions, following the release process on each, including building the source, testing it manually as the release process specifies, building the pkg or dmg, manually renaming it, for the newer OSes signing it with a paid Apple developer account ID, checksumming it, uploading it to SourceForge, updating the web site version numbers, updating the release URL.

Which is easier?