search

rems-project / lem

Lem semantic definition language
Other
130 stars 15 forks source link

Using lem as a dependency: add an OPAM package to the main repo? #29

Closed mgree closed 3 years ago

mgree commented 4 years ago

Satisfied lem user here! Thanks for the great work.

I'm currently overhauling Smoosh's build, with the aim of developing an OPAM package. Smoosh uses lem, which means that my OPAM package will need Lem. I see that #24 has already addressed this issue, but I'd like to reopen the question.

Unfortunately, I don't think it's possible for a package in the main OPAM repository to depend on packages in other repositories. I'd prefer not to ask users to have to add extra OPAM repos.

Also unfortunately, GitHub's releases don't include the submodule source, so I can't have Smoosh's OPAM package install lem on the sly (via lem's OPAM script or just copying the build). In the extreme, I could vendor the lem code into my project, but that feels brittle.

Are y'all interested in having a public lem OPAM package? I've got some (recent, hard-won) experience getting OPAM packages to work, and I'd be happy to take a whack at it... but I figured I'd check first.

One important consideration is that naming the package lem in the public OPAM repo may conflict with your setup as long as lem also exists in the rems-project OPAM repo. I figure we could either synchronize our movements or I could name the public package something different, e.g., lem-lang.

PeterSewell commented 4 years ago

In principle, maybe - but I suspect we don't have spare opam-fighting effort right now. I don't think there should be a separate package, which would inevitably slowly diverge and create confusion.

mgree commented 4 years ago

I'm okay with doing the OPAM fighting (for Lem, at least), but I won't start without your approval. I agree that having just one package is immensely preferable.

It's a tough spot for me, though: without a public Lem OPAM package, it seems like any standalone release of Smoosh in OPAM would need vendored code. But I'll investigate the possibility of using extra-source in my OPAM file to download a Lem release. (But I doubt that the OPAM installer will let me install Lem in .opam while building my own project, due to sandboxing rules.)

Do you have a sense of when---either in absolute time or in circumstances---it would make sense to migrate Lem to public OPAM?

PeterSewell commented 4 years ago

Hi Michael,

fyi, we're now having a push to get several things, including Lem, into public opam packages - in the next couple of weeks if we can.

best, Peter

On Tue, 19 May 2020 at 17:38, Michael Greenberg notifications@github.com wrote:

I'm okay with doing the OPAM fighting (for Lem, at least), but I won't start without your approval. I agree that having just one package is immensely preferable.

It's a tough spot for me, though: without a public Lem OPAM package, it seems like any standalone release of Smoosh in OPAM would need vendored code.

Do you have a sense of when---either in absolute time or in circumstances---it would make sense to migrate Lem to public OPAM?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rems-project/lem/issues/29#issuecomment-630939631, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFMZZT4MWJHXFE4UTZLA53RSKYY7ANCNFSM4NBWRJ4Q .

mgree commented 4 years ago

Great news! Please let me know if I can help in some way---I have battled the OPAM ogres[^1] and won before, and I'd be happy to do it again.

^[1]: Everyone on the OPAM project is very nice; publishing software is hard.

Alasdair commented 4 years ago

Should be available now:

https://opam.ocaml.org/packages/lem/

mgree commented 3 years ago

I've migrated to use lem from OPAM and everything works a treat. Thanks! 😀