Add a CLI subcommand to install Clojure Jar files in the virtualenv

[chrisrink10]

Fixes #668

I wanted to add this subcommand as a sort of provisional attempt to address #668. For now, the idea is to point basilisp install-jar [jar] to a *.jar file in your local Maven repository:

$ clojure -Sdeps '{:deps {org.clojure/tools.cli {:mvn/version "1.1.230"}}}'
$ basilisp install-jar  ~/.m2/repository/org/clojure/tools.cli/1.1.230/tools.cli-1.1.230.jar

Because Clojure's directory structure is generally compatible with Basilisp's and because Basilisp can read *.cljc files now, this should make the library immediately importable. However...

In testing this (very rudimentary) solution, I wasn't able to find almost any Clojure libraries that would load without some additional modifications. I tried to find "pure" Clojure libraries (such as medley and even tools.cli) but they typically lacked :lpy reader conditionals in one or more points in the code so it wouldn't load. Given the limited scope of Clojure libraries that might work with Basilisp out of the box, I question the value of this functionality.

I don't foresee this being the final format of this functionality, but until I'm able to really dig in on some of the tickets around project management I imagined something like this might be a decent stop gap.

[ikappaki]

(perhaps the following simple cljc lib could work out of the box as a test case without mods? https://github.com/borkdude/deflet)

[amano-kenji]

I think people interested in supporting basilisp should target basilisp pep517 build backend with pyproject.toml. You should add pyproject.toml to projects that you want to use?

Once you go down the rabbit hole of supporting jars, you may end up requiring JVM in a basilisp project.

Even if jar support doesn't require JVM, you should also consider whether it can be installed as a source package for linux distributions. One of the reasons that electron apps aren't generally added to linux distributions is it's very difficult to make a source package for linux distributions out of a node.js application. I think it hasn't been done before. You can still make binary packages, but linux distributions generally don't like binary packages. Linux distribution package maintainers like me highly prefer source packages that can be built from scratch.

If jar is not a part of proper basilisp project dependencies, jar should be a development tool, but not a packaging tool integrated into basilisp.edn or pyproject.toml. I don't yet know how I can package this outside a docker container. I think this setup won't be packaged outside docker containers.

Without a proper project management tool, dependencies usually become a mess(linux from scratch), or programs are not packaged and deployed. I have done linux packaging for years, and I take packaging seriously whether it's done in JVM ecosystem or linux distributions.

Dependency management outside an overarching packaging system becomes unmanageable quickly. I can't manage 1000+ packages on my linux system without a package manager.

My suggestion is to use pyproject.toml as the only form of dependency management. Otherwise, you lose simplicity. One unified packaging system generally makes me want to use a programming language.

[chrisrink10]

@amano-kenji as I said in the PR description:

I don't foresee this being the final format of this functionality, but until I'm able to really dig in on some of the tickets around project management I imagined something like this might be a decent stop gap.

In my ideal world, Clojure dependencies (from Clojars, Maven Central, etc.) and Basilisp/Python dependencies (from PyPI) would be declared in basilisp.edn (#755) and we would include them with some sort of build tooling (perhaps as you outlined in #1221). People have asked how they can use Clojure dependencies multiple times before and this would enable a very rudimentary form of using Clojure dependencies until I can deliver the more mature tooling that I would like to provide.

That being said, I haven't decided if I want to include this feature or continue to defer until I address the project management tooling.

[didibus]

In my ideal world, Clojure dependencies (from Clojars, Maven Central, etc.) and Basilisp/Python dependencies (from PyPI) would be declared in basilisp.edn (#755) and we would include them with some sort of build tooling (perhaps as you outlined in #1221). People have asked how they can use Clojure dependencies multiple times before and this would enable a very rudimentary form of using Clojure dependencies until I can deliver the more mature tooling that I would like to provide.

This is an interesting decision, I feel from ClojureScript, had the choice embraced npm package management from the start a lot less headaches would have ensued. But I think it depends on what people end up doing the most. Do they end up using libraries from Clojure (cljc), or do they end up using mostly libraries from Python. You also have the issue of, in ClojureScript, it's really hard to write a lib to be consumed by other JS code, and here too, if Basilisp used it's own dependency definition/feature, would it prevent Basilisp packages from being consumed by Python ones? Or more importantly, prevent packaging of Basilisp apps/libs to be consumed by Python users? Could one do pip install my-basilisp-app for example.