project.janet, pure datastructures mode?

[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 as declare-project, declare-executable, etc.? For instance,

{:declare :project 
 :name ...}

or

[:declare-project 
 {:name ... }]

[subsetpark]

Or even, to make it requireable, something like

(def project
 {:name ...})

[pepe]

What would be the advantage of this? I am not sure, I understand this, and I would like to :-)

[subsetpark]

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.

[pepe]

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?

[subsetpark]

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.

[pepe]

Thank you!

[bakpakin]

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

[pepe]

I guess we could create configure issue and close this one?

[sogaiu]

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?