Re: More OCaml ports for /dev/null?

[Cyril Roelandt]

On 2019-04-02 18:54, Anil Madhavapeddy wrote:
> On 2 Apr 2019, at 18:26, Cyril Roelandt  wrote:
> > 
> > (I'm the author of upt. Please keep me CCed)
> > 
> > On 2019-04-02 12:58, Daniel Jakots wrote:
> >> You can look at sysutils/upt. It's not something specific for OpenBSD.
> >> It works with "frontends" (language-specific packages systems, cpan pip
> >> etc) and "backends" (OS-specific packages systems). There's already an
> >> OpenBSD backend so you need to only add a ocaml frontend.
> > 
> > That is a good summary of how upt works. The idea is that every time a
> > new frontend is added (for Hackage or NPM, for instance), minimal effort
> > is required to add support for it on the OpenBSD side. Support for PyPI
> > is just one simple class[1] and one short Jinja2 template[2].
> > 
> > Instead of writing a new backend for PortGen, you could write a new
> > frontend for upt :) It would also help package managers who use other
> > operating systems (hey, nobody's perfect!).
> > 
> > I'm willing to help with this if you're interested in using upt.
> 
> This also looks very cool!  How does it deal with mapping system
> dependencies that a package needs into the ports Makefile?

The frontend is OS-agnostic. It gathers metadata about a package, and
allows all backends (OpenBSD, Nix, Fedora...) to see metadata from
various package managers in a unified intermediate representation.

It is then up to the upt backends to map dependencies properly. For
instance, a Python package named "foo" upstream will be named "py-foo"
in OpenBSD. The OpenBSD backend could be modified to use depexts to
find all OS packages that need to be installed.


Cyril

Re: More OCaml ports for /dev/null?

[Anil Madhavapeddy]

On 2 Apr 2019, at 18:26, Cyril Roelandt  wrote:
> 
> (I'm the author of upt. Please keep me CCed)
> 
> On 2019-04-02 12:58, Daniel Jakots wrote:
>> You can look at sysutils/upt. It's not something specific for OpenBSD.
>> It works with "frontends" (language-specific packages systems, cpan pip
>> etc) and "backends" (OS-specific packages systems). There's already an
>> OpenBSD backend so you need to only add a ocaml frontend.
> 
> That is a good summary of how upt works. The idea is that every time a
> new frontend is added (for Hackage or NPM, for instance), minimal effort
> is required to add support for it on the OpenBSD side. Support for PyPI
> is just one simple class[1] and one short Jinja2 template[2].
> 
> Instead of writing a new backend for PortGen, you could write a new
> frontend for upt :) It would also help package managers who use other
> operating systems (hey, nobody's perfect!).
> 
> I'm willing to help with this if you're interested in using upt.

This also looks very cool!  How does it deal with mapping system
dependencies that a package needs into the ports Makefile?

opam has something called a 'depexts' field (see
https://github.com/ocaml/opam-depext ) 
which records a mapping of
system OS package name that can be installed by that package 
manager to satisfying C libraries that are needed.  That needs to
be mapped into the OpenBSD Makefile as well.

Anil

Re: More OCaml ports for /dev/null?

[Cyril Roelandt]

(I'm the author of upt. Please keep me CCed)

On 2019-04-02 12:58, Daniel Jakots wrote:
> You can look at sysutils/upt. It's not something specific for OpenBSD.
> It works with "frontends" (language-specific packages systems, cpan pip
> etc) and "backends" (OS-specific packages systems). There's already an
> OpenBSD backend so you need to only add a ocaml frontend.

That is a good summary of how upt works. The idea is that every time a
new frontend is added (for Hackage or NPM, for instance), minimal effort
is required to add support for it on the OpenBSD side. Support for PyPI
is just one simple class[1] and one short Jinja2 template[2].

Instead of writing a new backend for PortGen, you could write a new
frontend for upt :) It would also help package managers who use other
operating systems (hey, nobody's perfect!).

I'm willing to help with this if you're interested in using upt.

Regards,
Cyril

[1] 
https://framagit.org/upt/upt-openbsd/blob/master/upt_openbsd/upt_openbsd.py#L215
[2] 
https://framagit.org/upt/upt-openbsd/blob/master/upt_openbsd/templates/python.mk

Re: More OCaml ports for /dev/null?

[Anil Madhavapeddy]

> On 2 Apr 2019, at 13:12, Ian Darwin  wrote:
> 
>> Adding support to portgen would be ideal ..
> 
> Exactly what I was going to say, but Stuart beat me to it. This would be 
> ideal for OpenBSD;
> hopefully not too non-ideal for upstream.
> 
>> Adding something to directly build a package from outside ports
>> infrastructure is not so good
> 
> Yup. And remember that OpenBSD ports cannot fetch files over the net during 
> bulk
> builds, so portgen is the best option, something else that builds a port in
> the same manner is next (but why reinvent the thing?).
> 
> Installing outside of the ports system would be treated as renegade by the
> project and as a pain in the arse for users. I also have a Mac and have to
> install crap from Apple store, from brew, from at least one other other
> ports system, directly from some vendors, some as .dmg and some as .pkg. 
> Updating is such a frickin' mess I have all but given up trying to keep that
> system up to date! OBSD is the very best because you can just do pkg_add -vu
> and update all third-party software.

portgen is _exactly_ what I was looking for, thanks!  I'll look into supporting
that first in the new dune infrastructure for this.

I'm the first user on my laptop, so I really want `pkg_add -u` to just work
for myself :-)

Anil

Re: More OCaml ports for /dev/null?

[Daniel Jakots]

On Tue, 2 Apr 2019 11:50:32 +0200, Christopher Zimmermann
 wrote:

> On Tue, 2 Apr 2019 10:41:58 +0100
> Anil Madhavapeddy  wrote:
> 
> > I’m also working on a non-April fools joke, which is sufficient
> > metadata in dune to generate reliable openbsd ports. So in a few
> > months, we should be able to type in package names and have
> > reasonable Makefiles output for the ports (including WANTLIB etc).
> > Am doing it for Homebrew and a few other operating systems as well
> > to see if we can sidestep the port maintainer burden somewhat.
> > Unsure yet if it’ll be suitable for usage in OpenBSD, but at a
> > minimum it’ll generate sufficient scaffolding for a human ports
> > maintainer to tweak for upstreaming.  
> 
> That's an interesting idea, I also thought about, but was wondering
> whether to generate the port from OPAM metadata or create a package
> from opam builds. This would obviously not integrate with the ports
> infrastructure. But would it even need to?

You can look at sysutils/upt. It's not something specific for OpenBSD.
It works with "frontends" (language-specific packages systems, cpan pip
etc) and "backends" (OS-specific packages systems). There's already an
OpenBSD backend so you need to only add a ocaml frontend.

I used it for python ports and it does a lot of the grunt work.

cc (per his request) the author


Cheers,
Daniel

Re: More OCaml ports for /dev/null?

[Anil Madhavapeddy]

On 31 Mar 2019, at 04:29, Kenneth Westerback  wrote:
> 
> My full table is on cvs as ~krw/ocamlports.org .
> 
> I have
> 
> devel/ocaml-uutf
> lang/ocaml-camlp5
> math/ocaml-num
> math/ocaml-zarith
> devel/dune
> 
> as candidates for removal since they don't appear to be used by any end-user 
> program.

greetings! 

dune will soon be used by Coq as well (we’re just finalising the build 
integration upstream).  We’re also separating out the dune “binary” from the 
dune “libraries” so the host build tool can be installed independently of any 
particular OCaml version.  This will make it possible to build OCaml itself 
using dune in the future, so it’s useful to keep it installing the binary.

(Christophe: that dune patch I sent you to install the ocaml libraries for 
dune.configurator prompted this train of thought — I now think the current port 
is better and that we should have a separate dune library package)

In general, it would be good to keep the ‘host binaries’ for OCaml tools in 
ports, and to retire the libraries that not used by other ports.

I’m also working on a non-April fools joke, which is sufficient metadata in 
dune to generate reliable openbsd ports. So in a few months, we should be able 
to type in package names and have reasonable Makefiles output for the ports 
(including WANTLIB etc).  Am doing it for Homebrew and a few other operating 
systems as well to see if we can sidestep the port maintainer burden somewhat.  
Unsure yet if it’ll be suitable for usage in OpenBSD, but at a minimum it’ll 
generate sufficient scaffolding for a human ports maintainer to tweak for 
upstreaming.

> 
> For anyone who hasn't stumbled across it, there is an inspirational video on 
> youtube about the OCaml Platform vision. Presented by a grizzled veteran of 
> the OCaml wars who looks tantalizingly familiar.
> 
> https://m.youtube.com/watch?v=oyeKLAYPmQQ 
> 
Unbelievable talk! Such poise and grace!

Anil

Re: More OCaml ports for /dev/null?

[Ian Darwin]

> Adding support to portgen would be ideal ..

Exactly what I was going to say, but Stuart beat me to it. This would be ideal 
for OpenBSD;
hopefully not too non-ideal for upstream.

> Adding something to directly build a package from outside ports
> infrastructure is not so good

Yup. And remember that OpenBSD ports cannot fetch files over the net during bulk
builds, so portgen is the best option, something else that builds a port in
the same manner is next (but why reinvent the thing?).

Installing outside of the ports system would be treated as renegade by the
project and as a pain in the arse for users. I also have a Mac and have to
install crap from Apple store, from brew, from at least one other other
ports system, directly from some vendors, some as .dmg and some as .pkg. 
Updating is such a frickin' mess I have all but given up trying to keep that
system up to date! OBSD is the very best because you can just do pkg_add -vu
and update all third-party software.

Re: More OCaml ports for /dev/null?

[Stuart Henderson]

On 2019/04/02 11:50, Christopher Zimmermann wrote:
> On Tue, 2 Apr 2019 10:41:58 +0100
> Anil Madhavapeddy  wrote:
> 
> > I’m also working on a non-April fools joke, which is sufficient
> > metadata in dune to generate reliable openbsd ports. So in a few
> > months, we should be able to type in package names and have
> > reasonable Makefiles output for the ports (including WANTLIB etc).
> > Am doing it for Homebrew and a few other operating systems as well to
> > see if we can sidestep the port maintainer burden somewhat.  Unsure
> > yet if it’ll be suitable for usage in OpenBSD, but at a minimum it’ll
> > generate sufficient scaffolding for a human ports maintainer to tweak
> > for upstreaming.
> 
> That's an interesting idea, I also thought about, but was wondering
> whether to generate the port from OPAM metadata or create a package
> from opam builds. This would obviously not integrate with the ports
> infrastructure. But would it even need to?
> 
> Christopher

Adding support to portgen would be ideal ..

Adding something to directly build a package from outside ports
infrastructure is not so good

Re: More OCaml ports for /dev/null?

[Stuart Henderson]

On 2019/04/02 10:04, Christopher Zimmermann wrote:
> Hi,
> 
> my list of obsolete ocaml ports has been removed from devel/Makefile

I removed the unhooked ones because there was support and gentle
prods from various people and nobody else had got round to it :)

> and is therefore disabled. How do I delete the ports from cvs?
> Simply 'cvs remove' all files in the ports directories?

e.g.

cd /usr/ports/devel
cvs rm -Rf cudf
cvs commit cudf

> Can anyone tell me why I can't find the dependants of ocaml-num with
> this command:
> sqlite3 /usr/local/share/sqlports 'SELECT FULLPKGPATH FROM Depends \
> WHERE DEPENDSPATH LIKE "math/ocaml-num"'

Works for me

$ sqlite3 /usr/local/share/sqlports 'select fullpkgpath from depends where 
dependspath like "math/ocaml-num"'
devel/cil
devel/coccinelle
math/coq
net/mldonkey

though as you're just doing an equality search it might as well be
'dependspath="math/ocaml-num"' (or you could do e.g. 'like "%ocaml-num%"').

Re: More OCaml ports for /dev/null?

[Christopher Zimmermann]

On Tue, 2 Apr 2019 10:41:58 +0100
Anil Madhavapeddy  wrote:

> I’m also working on a non-April fools joke, which is sufficient
> metadata in dune to generate reliable openbsd ports. So in a few
> months, we should be able to type in package names and have
> reasonable Makefiles output for the ports (including WANTLIB etc).
> Am doing it for Homebrew and a few other operating systems as well to
> see if we can sidestep the port maintainer burden somewhat.  Unsure
> yet if it’ll be suitable for usage in OpenBSD, but at a minimum it’ll
> generate sufficient scaffolding for a human ports maintainer to tweak
> for upstreaming.

That's an interesting idea, I also thought about, but was wondering
whether to generate the port from OPAM metadata or create a package
from opam builds. This would obviously not integrate with the ports
infrastructure. But would it even need to?

Christopher



-- 
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
CB07 DA40 B0B6 571D 35E2  0DEF 87E2 92A7 13E5 DEE1


pgp2_5pYSBJg9.pgp
Description: OpenPGP digital signature

Re: More OCaml ports for /dev/null?

[Jeremie Courreges-Anglas]

On Tue, Apr 02 2019, Christopher Zimmermann  wrote:
> Hi,
>
> my list of obsolete ocaml ports has been removed from devel/Makefile
> and is therefore disabled. How do I delete the ports from cvs?
> Simply 'cvs remove' all files in the ports directories?

cvs rm -f 
cvs commit 

> On Sun, 31 Mar 2019 11:29:02 +0800
> Kenneth Westerback  wrote:
>> I have
>> 
>> devel/ocaml-uutf
>> lang/ocaml-camlp5
>> math/ocaml-num
>
> used by devel/{coccinelle,cil}

ocaml-camlp5 and ocaml-num are used indeed, but devel/ocaml-uutf doesn't
seem to be used anywhere, so I don't see a reason to keep it.

>> math/ocaml-zarith
>
> math/ocaml-zarith is used by devel/frama-c
>
>> devel/dune
>> 
>> as candidates for removal since they don't appear to be used by any
>> end-user program.
>
> zarith is supposed to replace num.
> At the moment I would keep devel/dune, because it is so very widely
> used.

I would agree with you but:
- no consumer means no easy way to test, and the current make test
  failures don't make me very confident.
- it's already lagging behind upstream, 1.7.2 vs 1.8.2.  Anil had
  an update diff but nobody commented on it.

If dune is only useful to build libraries/programs shipped by opam, then
maybe dune should be shipped by opam too?

> Can anyone tell me why I can't find the dependants of ocaml-num with
> this command:
> sqlite3 /usr/local/share/sqlports 'SELECT FULLPKGPATH FROM Depends \
> WHERE DEPENDSPATH LIKE "math/ocaml-num"'

Works for me (tm), amd64-current.

ritchie ~$ sqlite3 /usr/local/share/sqlports 'SELECT FULLPKGPATH FROM Depends 
WHERE DEPENDSPATH LIKE "math/ocaml-num"'
devel/cil
devel/coccinelle
math/coq
net/mldonkey

>
> Christopher

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: More OCaml ports for /dev/null?

[kwesterback]

> On Apr 2, 2019, at 4:04 PM, Christopher Zimmermann  wrote:
> 
> Hi,
> 
> my list of obsolete ocaml ports has been removed from devel/Makefile
> and is therefore disabled. How do I delete the ports from cvs?
> Simply 'cvs remove' all files in the ports directories?
> 
> On Sun, 31 Mar 2019 11:29:02 +0800
> Kenneth Westerback  wrote:
>> I have
>> 
>> devel/ocaml-uutf
>> lang/ocaml-camlp5
>> math/ocaml-num
> 
> used by devel/{coccinelle,cil}
> 
>> math/ocaml-zarith
> 
> math/ocaml-zarith is used by devel/frama-c
> 
>> devel/dune
>> 
>> as candidates for removal since they don't appear to be used by any
>> end-user program.
> 
> zarith is supposed to replace num.
> At the moment I would keep devel/dune, because it is so very widely
> used.
> 
> Can anyone tell me why I can't find the dependants of ocaml-num with
> this command:
> sqlite3 /usr/local/share/sqlports 'SELECT FULLPKGPATH FROM Depends \
> WHERE DEPENDSPATH LIKE "math/ocaml-num"'
> 
> 
> Christopher
> 
> 
> -- 
> http://gmerlin.de
> OpenPGP: http://gmerlin.de/christopher.pub
> CB07 DA40 B0B6 571D 35E2  0DEF 87E2 92A7 13E5 DEE1

Jasper also pointed out my shoddy dependency checking. :-) I put a newer 
ocamlports.org on cvs.

I have problem keeping dune. One can even hope the remaining ports are modified 
upstream to use modern build tools. :-)

 Ken

Re: More OCaml ports for /dev/null?

[Christopher Zimmermann]

Hi,

my list of obsolete ocaml ports has been removed from devel/Makefile
and is therefore disabled. How do I delete the ports from cvs?
Simply 'cvs remove' all files in the ports directories?

On Sun, 31 Mar 2019 11:29:02 +0800
Kenneth Westerback  wrote:
> I have
> 
> devel/ocaml-uutf
> lang/ocaml-camlp5
> math/ocaml-num

used by devel/{coccinelle,cil}

> math/ocaml-zarith

math/ocaml-zarith is used by devel/frama-c

> devel/dune
> 
> as candidates for removal since they don't appear to be used by any
> end-user program.

zarith is supposed to replace num.
At the moment I would keep devel/dune, because it is so very widely
used.

Can anyone tell me why I can't find the dependants of ocaml-num with
this command:
sqlite3 /usr/local/share/sqlports 'SELECT FULLPKGPATH FROM Depends \
WHERE DEPENDSPATH LIKE "math/ocaml-num"'


Christopher


-- 
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
CB07 DA40 B0B6 571D 35E2  0DEF 87E2 92A7 13E5 DEE1


pgpP8RiqIljN1.pgp
Description: OpenPGP digital signature