[Feature] Please add `jrun install -r requirements.jrun` syntax

[jleaders]

I know jrun is primarily for running java, but it strikes me as being a possibly remarkably simple dependency manager. (groovy, gradle, ant, maven all seem quite complex)

This request is not without precedent, see the following technologies who employ this pattern:

• gem
• npm
• bower
• pip
• composer
• ansible-galaxy

You could make it pip-like "one line, multi-depeandancy install" behavior, similar to pip install -r requirements.txt. What do you think of creating a jrun install that does the same thing that jrun is currently doing, but also copies the downloaded artifacts to a specified folder (--out)?

I'm imagining:

$ cat requirements.jrun

net.razorvine:pyrolite
# insert more dependancies here... also support PURL syntax?

$jrun install --requirements requirements.jrun --out ./lib is the same as $jrun install -r requirements.jrun -o ./lib Which then results in: $tree ./lib

./lib
└── net.razorvine
    └── pyrolite
        ├── pom.xml
        ├── pyrolite-4.21.jar
        └── serpent-1.23.jar

Then any java project could just add ./lib as it's library path, and just create a jrun.requirements for all their dependency management

This will satisfy the heart of this request which has 25,000 views https://stackoverflow.com/questions/2710266/is-there-a-package-manager-for-java-like-easy-install-for-python

[jleaders]

Alternatively you could an additional binary called jip or jpkg that does this, so jrun is still seperated

[ctrueden]

Nice idea, @jleaders.

I am naturally reluctant to complexify jrun, but on the other hand being able to specify a composite endpoint using a requirements file is compelling. And adding an option to not actually run the resulting environment would also be very easy. As would adding an option to configure the destination directory of the environment.

Before we dive into it further, I'd like to mention a conversation started on conda-forge about how best to package Java components for conda: conda-forge/conda-forge.github.io#590. If we can establish some best practices and/or tooling for wrapping Maven artifacts as conda packages, it might fulfill what you are looking for. What do you think?

[hanslovsky]

And adding an option to not actually run the resulting environment would also be very easy.

The python port (#12) does that already (albeit only within python code) and I use that to be more flexible in imglyb.

[ctrueden]

@jleaders Does the python port fulfill your needs here? Shall we close this? Or do you think there is value in implementing something that works with the shell script version as well?

[jleaders]

If from your readme I can easily know how to install packages with CLI one liners then yes

[hanslovsky]

The python script does not expose dependency resolution to the command line, only as a utility method to be called from other python projects. If you would like to (change and) expose that as CLI functionality, PRs are always welcome.

[hanslovsky]

37 adds a --resolve-only options which prints the directory containing all the jars to the command line. You could then just copy all the jars in that directory to where you need them.

$ ls `jgo --resolve-only net.imglib2:imglib2-algorithm`
ejml-0.24.jar  imglib2-5.6.0.jar  imglib2-algorithm-0.11.1.jar  imglib2-realtransform-2.0.1.jar  imglib2-roi-0.6.0.jar  jama-1.0.3.jar  jitk-tps-3.0.0.jar  log4j-1.2.17.jar  ojalgo-45.1.1.jar  pom.xml  trove4j-3.0.3.jar
$ cp `jgo --resolve-only net.imglib2:imglib2-algorithm`/*.jar <target-dir>

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/installing-imagej-plugins-with-python/68368/2