Closed shonfeder closed 3 years ago
It should be possible for users to set their own default templates via ~/.config/dune/config.
Could you expand on this a little more? Is the idea for the user to set preferences for existing templates? or is the goal to define new templates?
If it's the latter, then I would prefer that we first implement for defining public/private templates first. In other words, the same semantics we have for executables & libraries. I think only then we can start talking about allowing the user to have a store for private templates.
The latter. (I have not considered preferences for templates. Are preferences needed when you can just make a variation of a template to suite your needs?) The idea is, a user may always want projects to use base
or containers
or certain ppxs, or they may always want to two libraries, or certain kinds of testing boilerplate (or anything really), and they should be able to achieve all of this with a custom template.
I'm actually not clear on the public/private semantics for libraries and executables (which should help me understand). In the documentation, I can find two mentions that might be relevant. The first is about scope
:
scope: a scope determines where private items are visible. Private items include libraries or binaries that will not be installed.
But I haven't found anything that explains how to declare an executable as private.
The other instance is in the private_modules
field of the library
stanza, but I don't see a corresponding field for executables.
Could you explain what would be the difference between a private template and a public template? In my understanding so far, a template is just a component (e.g., library, executable, project) skeleton, i.e. is some files with placeholders for string substitution -- it's not clear to me what a public/private semantics of such a template would be.
But I haven't found anything that explains how to declare an executable as private.
A private executable is one where the public_name
is omitted.
I haven't yet written down anything regarding defining/sharing templates. Let me write out some ideas I've had and they should answer most of your questions.
First, a template should be definable using the same construct we define other entities dune knows about - using stanzas. For example:
(template
(name foo) ;; in conjunction with $ dune init foo
(synopsis "short description here")
(source dir/)) ;; dir/ would contain the template files to instantiate this template.
The above would define a private template. Such a template remains visible only in its scope, so to prevent identically named templates from colliding. I suppose we could add a way to qualify the scopes in such a situation.
For templates to be installed & shared, they need to have a public_name
, and possibly be attached to a package. The idea is natural if you want templates to be distributed just like anything else. For example:
$ opam install opium
$ dune init opium.starter --name helloworld
Oh dope! Let me unpack a bit, to be sure I understand what you're proposing:
_build
directory they "build" to source code within the current scope (creating that scope if needed) -- of course with the caveat that they "build" via initialization.dune @install
?synopsis
field suggests we'll need to extend the init
command (or perhaps add a template
command) to be able to query available templates.I like the general shape of this a lot. Particularly, the idea that installed packages can be template-bearing: this opens the way for many "getting started" tutorials and "example" directories to be replaced with easy template generation. I think this would be a tremendous gain for accessibility in the ecosystem. :+1:
Assuming my understanding is correct, I have two followup questions:
opium
, but have no need for it's templates). So I wonder if we shouldn't require templates to be specified as a package, which can then be included in the depopts
? Otherwise, might we risk having to implement an embedded package manager in dune
? (Delegating this to the package manager might also save us the trouble of having to implement (c) ).[1]: Is there a better term we use for a "configurable unit", i.e., that which is to be built according to the configuration of a stanza?
The user story motivating private templates is not totally obvious to me -- I can vaguely guess at some possible scenarios, but a concrete example would help me here. Could you sketch out a case where a user would want a private template?
I agree that private templates aren't really useful. They're really more of an intermediate step to the full blown feature. In my mind, this can be implemented as a first step, and everything else can come in successive PR's.
It seems like this plan envisions templates as a kind of sub-package. This seems to be the kind of thing a user of a package may want to only include optionally during install (I may want opium, but have no need for it's templates)
Well this problem isn't unique to templates unfortunately. Packages are already magic boxes that can easily surprise you with extra libraries and executables that you don't really need or expect. I would say that we should just keep things uniform and address this problem down the road. At the very least, templates don't introduce dependencies on other packages so the footprint is minor in comparison to libraries & executables.
Otherwise, might we risk having to implement an embedded package manager in dune
Yeah, see the duniverse project everyone is aching for so badly :)
Is there a better term we use for a "configurable unit", i.e., that which is to be built according to the configuration of a stanza?
I'm not aware of one.
Thanks @rgrinberg. iiuc, the concrete steps can now be refined thus:
library
, executable
, test
, and project
components to the dune
package, using the new stanzainit
subcommand to initialize components using the aboveI should be able to get started on the first action item by next week.
Welp, 2020 went into a dark hole for me, and I'm only now emerging :)
In the interm, two quite fully featured approaches to project formatting have come on the scene:
I believe we decided that we're ok with offloading this task to external tools.
I'm closing this under that understanding. But if someone thinks this should still be open, please make some noise.
I'm the author of Spin, the project generator mentioned above.
I had been following the development of dune init
and was actually hoping that it would one day make tools like Spin obsolete. I think project generation is extremely important for newcomers and although I'm happy with the visibility Spin has had, it's clear to me it won't be able to bring as much value as Cargo or Mix's own project generation.
If it's not a priority, I'm happy to contribute it: There are a lot of overlaps between Spin's design and the design laid out in #159, so I think I'm in a good position to help on this.
This was part of the "level 2" plan for dune init, as noted in discussion around the originating issue https://github.com/ocaml/dune/issues/159#issuecomment-408586053
The continued desirability for this feature came up on discourse, most clearly articulated by mjambon. It was also discussed in the meeting earlier this week.
Some ideas:
dune subst
?dune init proj foo --inline-tests
should add theinline_tests
stanza to library components even if they are not in the template).library
,test
andexecutable
components.~/.config/dune/config
.--template foo
(which could search for a directory namedfoo
, and then fall back to a base name of a directory in the directory~/.config/dune/templates
.)Proposed initial course of action:
dune init proj
with the default template. (Ideas (1) to (4))Questions:
library
,test
, andexecutable
components?