basilisp project configuration file

[ikappaki]

Hi,

I'd like to propose the introduction of a project configuration file similar to Clojure's deps.edn to aid in various CLI project tasks. This file, perhaps named basilisp.edn or bsl.edn, could assist in determining the system path and external libraries required for building a project amongst other configuration options.

For instance:

basilisp.edn

{:paths ["src" "tests"]}

I'm considering of enabling nREPL server jack-in support for Emacs' CIDER and Visual Studio Calva packages. At this point, I only require a filename at the root of the project that these IDEs can use to recognize a Basilisp project. The details of what will be supported in this configuration file can be addressed later. For now, I'm seeking agreement on the filename. As a reference, Clojure JVM projects use deps.edn, babashka employs bb.edn, and nbb utilizes nbb.edn for their configuration files. I will also associate .lpy files with clojure mode as part of it.

thanks

[chrisrink10]

Let us go with basilisp.edn then. When this is added, we should note that the contents of such a file is as yet unspecified.

[amano-kenji]

#1221 is an alternative to basilisp.edn.

[amano-kenji]

As a veteran linux distro package maintainer, my perspective comes from my experiences with making linux packages for janet, raku, Go, Rust, python, C, C++, and haskell programs.

ClojureScript runs on JVM, so it's natural for clojurescript to have jvm dependencies. Most clojure(script) projects rely on JVM features, so basilisp can't just run them.

If basilisp tries to recognize deps.edn or project.clj(lein) in formal basilisp project dependencies and install JVM dependencies as python libraries, basilisp is likely to require JVM in order to resolve transitive dependencies and do other things to make them compatible with basilisp. JVM dependencies are also going to prevent basilisp from becoming a self-hosting pep517 build backend. That means python can't just install and import basilisp libraries as python libraries anymore.

Complecting basilisp with JVM ecosystem is also very likely to make it practically impossible to turn basilisp projects into linux distro system packages.

On the other hand, if we focus on basilisp/python dependencies in pyproject.toml and perhaps also basilisp.edn for extra stuff, then basilisp projects will be automatically compatible with system package managers and also various pep517 build frontends like pip and poetry.

Language package managers should be compatible with system package managers like gentoo portage, pacman, and GNU guix.

For streamlined developer/packaging experience, we should try to port existing clojure projects to basilisp by slapping lpy reader conditionals and pyproject.toml on these projects. Complecting basilisp with JVM ecosystem is not going to end well.

Going all the way with pyproject.toml and maybe basilisp.edn is the way.