[new release] config (0.0.1)

[leostera]

Ergonomic, lightweight conditional compilation through attributes

• Project page: https://github.com/leostera/config.ml

CHANGES:

0.0.1

Initial release with support for:

• Not, Any, and All expressions in the boolean language
• Checking for environment variables
• Providing target_os, target_arch, and target_env
• Support disabling module expressions and entire modules

[leostera]

I'd wait just a bit here, I think we can cram another use-case for this ppx into this release :)

[raphael-proust]

@leostera if you want to wait, can you mark this PR as draft (and then unmark it when you are done)?

Alternatively, if there are no issues, we could merge this and you can make a point release afterwards. What's your preference?

[hannesm]

I find this package name as well pretty confusing.

[leostera]

@raphael-proust thanks for the note, i'll make sure to keep draft PRs for releases on hold 🙏🏼 – it should be good to release once CI is green tho :)

@hannesm I'm open to suggestions, I picked config since that's the name of the macro you'd use to configure the builds.

[yawaramin]

And I guess also because it's inspired by Rust's conditional compilation with the #[cfg] attribute and macro?

Alternatively, would [@@if ...] be possible?

[leostera]

@yawaramin i'd like to keep this as simple as possible, so limiting it to not, all, any. If it's good enough for Rust it's probably good enough for us too. We can always extend but I think there's other dimensions to extend this in first (like arbitrary expressions).

@raphael-proust hm, CI doesn't even start on this one. Any thoughts? 🤔

[yawaramin]

@leostera sorry, I didn't explain myself clearly. If we assume that people will get confused by the name 'config', then maybe they wouldn't be confused by the name 'if' which can be seen as similar to other compile-time macros like C's #if. So eg:

module A = A_unix [@@if any(target_os = "macos", target_os = "linux")]
module A = A_win32 [@@if any(target_os = "windows")]

And we can explain this as 'it's just a compile-time if'.

Then we could also call the package ppx_if and conform to modern PPX naming practices.

[mseri]

Since this is a ppx, I would suggest ppx_if, ppx_buildtime_config, or somethinf on those lines, otherwise I agree that it is confusing

[leostera]

Naming aside, any thoughts on why the CI won't run here?

[leostera]

Okay, it seems that CI is running now.

[mseri]

It got stuck with one of the large PR and did not restart properly, but I see you retriggered it already :)

[leostera]

Would everyone be happy if I called this package cfg instead? I don't wanna clamp it to be just a ppx since there's a runtime component to it and I'd like to grow that to include overriding config via files, as well as packaging that config into type-safe modules for use at runtime.

edit: cfg is taken by a context-free-grammars package 🙃 – if config is truly such a deal breaker, I'll find a completely unrelated name like fig and move on.

[yawaramin]

I don't have a strong objection to config especially if the package is really about application configuration. I had thought it was intended to be a PPX for conditional compilation hence why I suggested ppx_if.

[leostera]

This version includes only the ppx and a few constants defined at load-time for the current target os, arch, and environment (gnu,musl,msvc).

But for example, I'd like to use this to map and load a config.toml file to configure the Riot runtime, or specific things on libc.ml.

[dinosaure]

edit: cfg is taken by a context-free-grammars package 🙃 – if config is truly such a deal breaker, I'll find a completely unrelated name like fig and move on.

It's preferable, I think. On the question of names, you have to separate several things:

• certainly the appearance of packages at a memorable time when we were coding with OCaml 3.12 - and when, obviously, we didn't imagine the appearance of ~4000 packages later (and when the question of names wasn't so important).
• on the other hand, there are packages for which we could make the same criticism and I'm obliged to mention packages like http where we can question the legitimacy of the maintainers/authors being able to use such a name when other implementations of the protocol exist.
• there are also packages with generic names such as decoders but whose kinship with Elm decoders is assumed. It is also a library that supports as many encodings as possible. It's hard to say whether it's right for this library to have this name or not.
• finally, there are also conventions such as conf- packages.

There are currently no rules imposed on names, but we should clarify this point and avoid situations like this. The problem is that the name (and the idea) config can refer to all sorts of things:

• does it also generate configuration files?
• What is the format (Debian? Toml? Yaml?...) and does this package (like decoders) handle them all?
• does it refer to ocamlc -config?
• Does it allow you to obtain the system configuration?
• or is it a standard way of getting a user's configuration files?

More concretely, there has already been a naming problem with ocamlscript for the example. It was supposed to be the original name of bucklescript but the project already existed. This problem shows that behind a generic name like ocamlscript, you can have several ideas. In this case, a tool for compiling OCaml scripts or an OCaml to JavaScript compiler.

There are several ways of solving the problem:

• For my part, and being the author of fairly generic libraries, I prefer to have fun with names (like digestif, checkseum or even emile).
• OCaml Pro (or Mirage to some extent) prefix their packages with ocp-. This way, they can use generic words

That's my two cents.

[leostera]

Honestly folks, I really think we're approaching this from the wrong angle.

The name is not offensive, its not intended to confuse (its not called ocaml-config, or dune-config), and there is working code that is being used somewhere (so there's no obnoxious intentional name squatting).

Anything else on top of this feels a little gate-keepey, specially considering there's no clear guidelines for how to name things, just some implicit conventions.

In other words, I'd expect my packages to get published if the name is available, and the above criteria passes, in a first-come-first-served basis. But I will recognize that these are my expectations coming from other ecosystems.

In any case, I'm waiting on this release to release #25074 and #25201 so I'd love whoever has authority over what goes and doesn't go into opam to just give me a thumbs up or down so I know what to do.

[hannesm]

"name is available on a first-come first-serve basis"

I'm fine with such a policy. We have "base", "core", "http", "h2" and somesuch already in opam-repository... (plus I myself (and others) have been pushing for "tls", "x509" etc.)

[dinosaure]

I think it still interesting to write down the policy about package names at least. Finally, I don't have strong opinion too on this specific package but the initial thoughts raise a real issue.

[mseri]

A few things:

• I agree that it will be interesting to write down a policy, since for example there is the unwritten policy that we don't allow packages with ocaml in the name (and for a while, I think it predates the time I joined) and recently we realized we should not allow packages differing by a "-" and an "_" because their library names will conflict

• In general we have followed name is available on a first-come first-serve basis as the policy, with very few exceptions for very generic names or names too close to other libraries (at least when we noticed, there will be an opam lint soonish about that)

I don't have a strong opinion about this (with a caveat, see the bottom of the comment) and I am happy to find together a community consensus. I am happy this PR raised the discussion though, since this policy is among the thing that we should figure out given the fast growth of the opam-repo.

For what is worth, I don't have a problem with the libc name in the other PR, but I agree with @dinosaure and I think that config can be confusing since it is a keyword or a flag in many ocaml-related tools (this is also easily arguable, since we have already configurator, config-file, configuration and we have allowed names like directories). I don't mind cfg or any other name to be honest. But this is just my opinion, and I think it is worth discussing it a moment here (or separately).

In any case, I don't want to take a unilateral decision but want to also hear your opinions (so thanks all for joining the discussion above!) and the opinion of the other maintainers. This will slow down a bit more the merge, I am really sorry about that 🙏

---

Caveat: if it was purely a ppx package, the standard is to keep ppx in the name, I think it makes sense to keep it that way

[avsm]

(this is also easily arguable, since we have already configurator, config-file, configuration and we have allowed names like directories)

Given the existence of all these variants, I don't think we shouldn't suddenly put in a barrier to this package. I'm fine with a library called config here. (Although, if @leostera is willing, you could also call it configml to avoid any future confusion. But that's entirely up to you.)

[mseri]

Just to be clear, my problem is not really that the name is generic, but I find it confusing that it has the name of an opam subcommand: opam config has a meaning and to me opam install config then feels weird. In this sense I think the config name is special (like init, exec, env, (re/un)install, lint, admin, clean, remove).

I agree that we should not block this on a policy discussion when the policy is not there, but I'll wait to see if @leostera is willing to make a name change for this specific package.

[yawaramin]

@mseri also relates to the question of opam not having namespaces, I imagine if we had namespaces like eg opam install @leostera/config then the command would be pretty unambiguous 🙂

[yawaramin]

To expand on my thoughts a bit, should we have a policy to not allow package names which conflict with opam subcommand names? Eg maybe we want to avoid opam install install? Then, should that policy be implemented here manually by inspection, or maybe opam and dune can directly disallow toplevel package names which conflict with opam subcommands? But what if opam adds more subcommands in the future? Can potentially valid package names become invalid in future opam versions?

The point I am trying to make is that this problem is arising because of a syntactic ambiguity between opam subcommands and package names. Maybe even if we won't have namespaces, we should have some other way to disambiguate package names?

[leostera]

@mseri LGTM 🚀

[avsm]

I fail to see the syntactic ambiguity here, @yawaramin. opam config config is ugly, but not ambiguous, and plugin packages must be marked with a special flag. Do you have something else in mind?

[yawaramin]

Hi @avsm the issue was pointed out by mseri (that opam install install would be confusing) and I called it a syntactic ambiguity which is maybe the wrong term as it's perhaps not ambiguous to a parser but rather to humans, especially those not very familiar with the opam command line.

Maybe opam could deprecate unversioned package names in the command line and print out a message telling people to use a versioned package name instead:

$ opam install install
⚠️ Package names without versions are deprecated and will be unsupported in a future version. To get the latest available version, use opam install install.*

Installing install.1.2.3...