Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow customization of namespace entrypoint file name. #2648

Open
jordwalke opened this issue Sep 18, 2019 · 10 comments
Open

Allow customization of namespace entrypoint file name. #2648

jordwalke opened this issue Sep 18, 2019 · 10 comments

Comments

@jordwalke
Copy link
Contributor

@jordwalke jordwalke commented Sep 18, 2019

Feature request: Allow a library:

(library
  (name MyPackageMyLibrary)
  (public_name my-package.my-library)
)

To have an entry point file name other than MyPackageMyLibrary.ml/re.

Why?

@prometheansacrifice and I discovered a set of use cases that this feature unlocks. I think these use cases could end up benefiting the overall integrity of the ocaml ecosystem because it would help avoid namespace collisions.

Currently, people are defining libraries like:

(library
  (name MyLibrary)
  (public_name my-package.my-library)
)

One of the reasons they do this, is because they want to develop "My Library" - thus MyLibrary.ml/re. But what some don't realize is that when they use the same-name entry point file, that it is vulnerable to collisions if someone else in some other package were to also create a namespace of MyLibrary.

  • We want to encourage people to avoid collisions in namespaces.
  • Therefore we would encourage people to make their library namespaces pretty long, including their package name as the prefix.
  • But when developing these long-named-libraries, they want to use the more shorter file name.
  • If we don't make it easier for them use the shorter file name with a longer namespace, they're more likely to just use a shorter (more collision-prone) namespace - and the result is more collisions in the ecosystem.

One potential stanza option could be:

(library
  (name MyPackageMyLibrary)
  (main MyLibrary)
  (public_name my-package.my-library)
)

There are also other uses for customizing the entrypoint module name (something like an init.ml)

@jordwalke

This comment has been minimized.

Copy link
Contributor Author

@jordwalke jordwalke commented Sep 18, 2019

With this feature added, there are other remaining things to be done that make longer namespaces more manageable - and this feature doesn't propose solutions to those. But this is one feature that could unblock experimentation with those other patterns/conventions which Dune could eventually encode as a best practice.

@jordwalke

This comment has been minimized.

Copy link
Contributor Author

@jordwalke jordwalke commented Sep 18, 2019

Another feature that (in conjunction with this request) would make longer namespaces tolerable: #2649. If the feature in that issue were implemented (or if we generated Dune files to that effect) then this issue of allowing a custom entrypoint file name becomes more important.

@diml

This comment has been minimized.

Copy link
Member

@diml diml commented Sep 18, 2019

Just to make sure I understand the proposal correctly, is the idea that instead of writing a file myPackageMyLibrary.ml you would instead write a file myLibrary.ml but from the outside, modules of the library would still be accessed via MyPackageMyLibrary.X?

@jordwalke

This comment has been minimized.

Copy link
Contributor Author

@jordwalke jordwalke commented Sep 18, 2019

@diml Correct. This proposal is a bite sized feature that still requires you to access the longer module namespace from the outside. The linked issue I created then proposes some facilities for allowing you to rename them to something shorter at consumption time. I consider them separate proposals because there are other reasons why you might want the entrypoint module name to differ from the namespace name (for example, you main want a (main init.ml) etc.

@diml

This comment has been minimized.

Copy link
Member

@diml diml commented Sep 19, 2019

Ok, this proposal seems fine to me. The only thing to make sure of is that this works well with the tooling, i.e. merlin and odoc.

Do you want to give a shot at implementing this feature?

@jordwalke

This comment has been minimized.

Copy link
Contributor Author

@jordwalke jordwalke commented Sep 22, 2019

I think we can take a look at implementing, but we want to leave this open for more feedback and implement it in user space to see if this is as useful as we suspect it will be (I am optimistic).

@diml

This comment has been minimized.

Copy link
Member

@diml diml commented Sep 23, 2019

Sounds good. On the technical side, you need to edit the type Library.t and function Library.decode in src/dune/dune_file.ml to add a main field. You then need to adapt the last branch of the function Library.main_module_name and return the name set by the user instead of the inferred one. Then, if everything is already properly wired up it should just work. Once this works, you'll need to add a test in test/blackbox-tests/test-cases following the format of the other tests and add some documentation to the manual in doc/dune-files.rst.

@mjambon

This comment has been minimized.

Copy link

@mjambon mjambon commented Sep 23, 2019

I like this proposal because it allows the user to decouple the name of the library (external) from the name of the entry point (internal). The developer of a multi-library project could use Main.ml systematically for the entry point.

@diml

This comment has been minimized.

Copy link
Member

@diml diml commented Sep 24, 2019

Indeed. For the case where the entry point just contains the list of modules, we could also slightly extend this proposal so that one doesn't have to write a boring main.ml file. For instance by writing (main (implicit))

@jordwalke

This comment has been minimized.

Copy link
Contributor Author

@jordwalke jordwalke commented Sep 24, 2019

Thank you for the pointers, @diml - very helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.