changing default perl

[Daniel J. Luke]

On Nov 11, 2013, at 12:01 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> 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 didn't have it fully thought out yet - but something like Jeremy's proposal (ie, if there's a portfile, it takes precedence).

> 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”.

I don't know that a 'generic' dependency type is what we want, but maybe it's OK.

> Other ports would depend on e.g. CPAN’s Archive::Tar module with “depends_lib module:cpan:Archive::Tar”.

I don't know why this would be better than depends_lib mp-cpan:Archive::Tar (or something similar).

/especially/ if we use a name like Archive::Tar - something needs to translate that into what the port would be named and if it's not available then use our 'mp-cpan' to install it [a similar transform is necessary if we use 'p5-archive-tar' or something instead of Archive::Tar, but could probably be localized to mp-cpan].

> 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.

I still don't understand why this would go in _resources instead of in base.

It's a new dependency type + a new build type.

> Generally, to install or uninstall a PERL CPAN module,

'Perl' (http://www.perl.org/about/style-guide.html)

> you use the “cpan” command with some arguments.

or cpanm or the cpan shell (perl -MCPAN -e shell) or download + perl Makefile.PL && make && make test && make install, or ....

> 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.

or, someone could make a good working version with one of those examples and if it works out well it could be enhanced to support other things (ie, we don't need to design for every possible module system at once). As a project, we have a history of trying to build something generic and then eventually only using it one way (and being stuck with overly-generic design decisions).

>> 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,

process issue.

> making sure no untested fixes have been committed since the last release,

process issue

> making a source tarball,

should be automated

> firing up six different OS X versions,

we just shouldn't do this (current + previous release) and/or should be automated

> 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.

should be largely automated.

> Which is easier?

that's not my point, my point is that the release process should be made easy so we can do lots of releases. If we just rapidly push code via _resources (or whatever) then it's /like/ we did a release, but without version number ++ and associated testing - just so we can avoid the release process. Essentially pushing code out this way is a 'stealth release'.

--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke at geeklair.net ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+