maintaining packages in macports vs. in a language package manager

[Mojca Miklavec]

On 17 November 2017 at 07:11, Joshua Root wrote:
> On 2017-11-17 13:15 , Perry E. Metzger wrote:
>> I'm slowly cleaning up the OCaml ports.
>>
>> One of the things of note is that these days (and this wasn't true a
>> couple of years ago), OCaml encourages the use of the "opam" package
>> manager, which is something like the Ruby "Gems" system or various
>> other language specific package managers.
>>
>> 0) How do we handle builds of ports where the language maintainers
>> really would prefer that some language-specific package manager build
>> the package?

There are two options:

(1) We package the latest version of "opam" and let the users handle
the packages on their own. This means that we cannot package any piece
of software that depends on ocaml packages. Joshua pointed out an
equivalent of git: if we relied solely on CPAN to install Perl
modules, we could not provide a package for git. If we would only
package pip instead of lots of python modules alongside, we would not
be capable of installing many many many useful pieces of software that
depend on python modules, including the package we need for out
automated builds, but there are plenty other examples.

I cannot imagine not packaging perl and python modules in that way. We
mostly gave up with ruby modules, but that's the reason why MacPorts
doesn't provide you a port for "ruby-on-rails" for example. The npm is
another example of this approach. We basically ignore javascript
packages, but since this is mostly useful for web development, we are
not really hurt.

(2) Insist in installing separate ocaml-* packages as individual ports
and mostly ignoring what "opam" does (apart from maybe providing a
port for it). Note that we do have tools like "cpan2port" and
"pip2port" that help the developer to nearly automatically create a
package from CPAN or PyPI. For Perl and Python this is super
important. I don't know whether we have some super useful software
written in ocaml that is already packaged or that we would want to get
packaged. If the answer is yes, we should keep using this approach. If
the answer is no, there's no need to do this. It's definitely more
complex to do, but it gives you more freedom at the end.


The third option would be to have some communication going on between
macports and third-party package manager, so that MacPorts would keep
track of what exactly has been installed. But we are not there yet
(and will probably never be). This would be ideal, but would require
quite a bit of coding that's unlikely to ever happen.


Then you have some alternative approaches like a recently packaged
"grep replacement" written in go. In which case the Portfile for that
utility had to take it on its own shoulders to fetch all the
dependencies itself before being able to compile the software. That's
super ugly and running "opam" as part of build process of one MacPorts
port would be highly undesirable (not to say forbidden).

>> 1) Given that there are 289 ocaml- ports in devel/, should we have a
>> category for ocaml the way we do for ruby?
>
> Sounds reasonable.

Indeed. It makes sense to add a category and move them to a separate folder.

Mojca