Use parcom with submodules

[jonsterling]

This is a "question", not a bug:

I'm currently using parcom in JonPRL, which I compile using CM. Now, in order to get parcom installed, I had to use Smackage, parcom uses Smackage in order to get ahold of cmlib.

My preference would be to use parcom via a git submodule, in order to make the installation process as simple as possible (I don't want folks to have to install Smackage to get hacking); in this case, I would somehow direct parcom to the correct location of cmlib by hand. My thinking is that the simplest thing I can do is just write my own .cm file for parcom and use that in my parent repo rather than parcom.cm.

Is this workflow reasonable, or is there a better way that I should do this?

Thanks very much,
Jon Sterling

[jonsterling]

(Oh, and feel free to tell me that I should just give up and embrace Smackage.)

[jonsterling]

I have ended up making a shallow wrapper repository around parcom that does the following:

• Access the parcom source through a submodule
• Provide a new cm file for parcom which accesses cmlib through a path anchor, so that instances of cmlib may be shared between multiple dependencies

I have been using this manual dependency resolution scheme for a while now in the JonPRL proof assistant and it works pretty well. I think Smackage is a nice tool, but it would be nice if SML libraries would standardize on using path anchors, and then at the application level, the path anchor can be bound to a Smackage location.

[fsieczkowski]

Sorry for the extremely long time it took me to look at this, I haven't been using github much recently.

A separate .cm is definitely the right way to go, and I completely understand reluctance to force people to use smackage, it's not exactly opam-level usable at the moment. I haven't used path anchors before, if you could point me to some resources I could see if it makes sense to incorporate it into the mainline parcom (since it doesn't look like a lot of work).

Cheers,
-- Filip

[jonsterling]

@Finrod Great, thanks for the response! Tonight hopefully I'll give you some examples on how to use path anchors. I'm using them pretty heavily in the JonPRL project for my dependencies, and it seems to be working pretty well.

[jonsterling]

@Finrod Sorry I took so long to get around to this... The documentation of using path anchors is in the CM manual, section 5.1.4 (page 16).

You can see an example of them in action in my library sml-telescopes, where I have two .cm files: one called telescopes.cm, which delegates to a path anchor for locating its dependencies, and one called development.cm, which instantiates the path anchor at the submodule.

Now, you only really need to require a user to have a library installed in case you intend to export things that are of types defined in your dependency, and you want these things to be interoperable with other uses of that dependency in the user's codebase.

However, if (for instance) cmlib is just an implementation detail in this library, it might make a lot more sense to just include it as a submodule and import directly from it; I suppose the downside of this approach is code-bloat, but I tend to prefer it where possible since it makes libraries much easier to install and much less sensitive to versioning issues. In package ecosystems where you have many a lot of "code-reuse" and inter-depending libraries (like Haskell, for instance), I find that you pretty much always end up in a self-inflicted hell that is mostly avoidable in SML+CM (or ML Basis) through the use of local dependencies.

[jonsterling]

I just remembered that parcom actually uses types from cmlib in its public interface, so the second half of my comment above can be ignored 😄