[GSoC] Read packages from other various package managers

[Ryan Schmidt]

On Apr 25, 2013, at 08:41, Daniel J. Luke wrote:
> On Apr 24, 2013, at 11:35 PM, Ryan Schmidt wrote:
>> On Apr 24, 2013, at 15:23, Andre Murbach Maidl wrote:
>>> I'm a Computer Science student and I'm currently working with
>>> Lua, so I'm interested to propose a way to integrate rockspecs
>>> from luarocks to macports.
>>> 
>>> After my talking to neverpanic on the irc channel, I realized
>>> that a simple script to generate Portfiles from rockspecs
>>> wouldn't be enough for GSoC.
>>> 
>>> Then he told me that maybe an API to deal with 3rd-party
>>> package managers could be enough for GSoC.
>>> However, he also told me that there is an open question:
>>> do we need an API to achieve that, or can it be done
>>> with what we already have?
>> 
>> What other package managers are you thinking of? In what way do you want to integrate them with MacPorts?
>> 
>> MacPorts already has ports for packages from cpan and pecl, and from the ruby and python package repositories. Most of these are created manually, though for cpan there is the cpan2port script that can be used as a starting place.
> 
> It would be cool, for instance, if port could call out to a modified cpan (or cpanm, or something else) to have it build a perl module so we would always have every available perl module (I think someone mentioned that fbsd ports does something like that).


That's been talked about before. What happens when another port wants to declare a dependency on a CPAN module? Currently, that other port writes "depends_lib port:p5.12-foo-bar" or whatever, and through the subport directives of the perl5 portgroup, the file perl/p5-foo-bar/Portfile is found and its instructions are followed. If you're proposing that we no longer have a Portfile for every port, and that some ports exist "virtually" and are passed through somehow automatically to CPAN, then I worry that that's so different from how MacPorts works today that it would be a massive amount of work to get right, and could easily cause problems at various edge cases. And what happens if a CPAN module doesn't work for us out of the box? Do we then fall back on creating a normal Portfile so that we can patch the source etc.?

We do need a good way to get packages from other collections into MacPorts and keep them updated, but I thought we were going to do that by developing scripts to automate the creation of Portfiles, like cpan2port already does to create CPAN ports.



I initially wasn't sure if this is what was meant, and it now seems like it isn't, but I would not support an effort to integrate with package managers that compete with MacPorts for installing normal programs and libraries, for example Gentoo Portage or FreeBSD Ports or Debian APT.