Open subsetpark opened 2 years ago
Or even, to make it require
able, something like
(def project
{:name ...})
What would be the advantage of this? I am not sure, I understand this, and I would like to :-)
What would be the advantage of this? I am not sure, I understand this, and I would like to :-)
Though I suspect there are other advantages for more involved projects, the advantage that would be immediate for me is linting - right now my project.janet unnecessarily triggers my editor's linter because declare-project
et al are not recognized symbols.
Truth to be told, I have a special condition for project.janet
in my kakoune linter. And I am not missing that personally. Yet I can understand your pain. But wouldn't it be solvable with the jpm in the new incarnation?
Though I suspect there are other advantages for more involved projects
May you please elaborate?
Simply: the ability to require a project.janet file by an arbitrary Janet program would allow it to be used or mutated or constructed by any arbitrary code.
So for instance, if you had a complex Janet program with many dependencies, you might want a ‘configure’ step. If so, you could have a script which loads your project file but then makes additional programmatic changes based on the presence of dependencies and configure flags.
Thank you!
Certainly a possibility, but would require significant work. Agree that it would be helpful for project introspection as well, and you could even validate a project.jdn with a schema of some sort. Arbitrary code could live in certain keys if needed, so it's not any less flexible (if done well), but seriously, that is a lot of effort to fix linter issues.
As far as a ./configure
analog for jpm
, that is something that would be nice to have
I guess we could create configure issue and close this one?
A bit late to the party but wanted to note that in Clojure-land, presumably after many years of experience with Leiningen (and a bit of Boot), there's this bit about tools.build:
The philosophy behind tools.build is that your project build is inherently a program - a series of instructions to create one or more project artifacts from your project source files. We want to write this program with our favorite programming language, Clojure, and tools.build is a library of functions commonly needed for builds that can be connected together in flexible ways. Writing a build program does take a bit more code than other declarative approaches, but can be easily extended or customized far into the future, creating a build that grows with your project.
via: https://clojure.org/guides/tools_build
In any case, perhaps it does make sense to close this as @pepe mentioned before. What do you think @subsetpark?
Since
project.janet
is just a series of instructions to jpm, would it be feasible to make jpm recognize top-level datastructures that encode the same operations asdeclare-project
,declare-executable
, etc.? For instance,or