Allow companions to be satisfied by system dependencies

[felipecrs]

Hi,

I know this works:

$ pkgx +openjdk.org@17 +maven.apache.org -- mvn --version
Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Maven home: /home/felipecrs/.pkgx/maven.apache.org/v3.9.4
Java version: 17.0.10, vendor: tea.xyz, runtime: /home/felipecrs/.pkgx/openjdk.org/v17.0.10.6
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.15.146.1-microsoft-standard-wsl2", arch: "amd64", family: "unix"

But I want to install mvn, and still use java@17. How to do that?

The following does not work:

$ pkgx install mvn
$ pkgx install java@17
$ mvn --version
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /home/felipecrs/.pkgx/maven.apache.org/v3.9.6
Java version: 20.0.2, vendor: tea.xyz, runtime: /home/felipecrs/.pkgx/openjdk.org/v20.0.2.9
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.15.146.1-microsoft-standard-wsl2", arch: "amd64", family: "unix"

[dosubot]

🤖

Hey @felipecrs, back for more adventures with pkgx, I see! 😄 Hope you've been great since last time!

It seems like you're trying to set a specific version of Java to be used with Maven. The issue you're facing is due to the fact that Maven is using the latest installed version of Java, not the one you specified.

To ensure that Maven uses Java version 17, you can create a wrapper script that invokes Maven with the desired Java version. Here's how you can do it:

$ echo '#!/bin/sh' > ~/.local/bin/mvn
$ echo 'exec pkgx +openjdk.org@17 +maven.apache.org -- mvn "$@"' >> ~/.local/bin/mvn
$ chmod +x ~/.local/bin/mvn

This script will ensure that every time you run mvn, it will be executed with Java version 17. Please replace openjdk.org@17 with the actual URL and version number of the Java distribution you want to use.

This approach is similar to the one described in the pkgx-install.md document, where a wrapper script is used to ensure that a specific version of Node.js is used.

As for how pkgx handles the installation of multiple packages and their dependencies, you can refer to the explanation provided in the context. It describes the process in detail, based on the code found in src/prefab/install.ts.

I hope this helps! If you have any other questions, feel free to ask.

Sources

• docs/pkgx-install.md
• src/prefab/install.ts

About Dosu

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[felipecrs]

I can imagine a similar situation for npm with node, and poetry with python. I know poetry has python as a dependency, and npm has node as a dependency, so does mvn has java as a dependency, but perhaps they should not be automatically installed.

Maybe a concept of peer dependencies can be introduced, where mvn would list java as a peer dependency.

A peer dependency:

• Can still be automatically installed by pkgx if the system has no version available
• Means the pkgx will give preference to whatever is in the $PATH, unless explicit by the user (+openjdk.org)

Then I think it would work, i.e. ~/.local/bin/mvn would respect ~/.local/bin/java.

[mxcl]

$ env +java@17
$ mvn --version
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /Users/mxcl/.pkgx/maven.apache.org/v3.9.6
Java version: 17.0.10, vendor: tea.xyz, runtime: /Users/mxcl/.pkgx/openjdk.org/v17.0.10.6
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.2.1", arch: "aarch64", family: "mac"

pkgx install doesn’t make that version the default inside the pkgenv which I agree is confusing and possibly a good reason to deprecate it.

FYI your first line can just be:

$ pkgx +openjdk.org@17 mvn --version

If you in general by default want mvn to use java@17 then that's a good feature proposal that we should flesh out.

Otherwise typically I would suggest using devenvs with dev to accomplish the package range restrictions.

[felipecrs]

possibly a good reason to deprecate it.

Deprecate the install command?!

If you in general by default want mvn to use java@17 then that's a good feature proposal that we should flesh out.

Nah, I don't think any specific version should be preferred. But if one has to be chosen, I'd say latest LTS (currently 21) is a good default.

Otherwise typically I would suggest using devenvs with dev to accomplish the package range restrictions.

Well... this is complicated. I'm allergic to injecting things on shell. I work a lot with containers, IDEs and pipelines that does not always use a shell to execute commands (they just get invoked directly, for which they need to be in PATH).

[mxcl]

Nah, I don't think any specific version should be preferred. But if one has to be chosen, I'd say latest LTS (currently 21) is a good default.

Well I mean, you personally, as some kind of configuration.

Deprecate the install command?!

Hah, well I was thinking of making a separate tool that can install pkgs properly from the pkgx index. And then putting the existing install command into mash with a better name.

Well... this is complicated. I'm allergic to injecting things on shell. I work a lot with containers, IDEs and pipelines that does not always use a shell to execute commands (they just get invoked directly, for which they need to be in PATH).

Yeah I get that. You can still inject it temporarily with:

$ eval $(pkgx +java@17)

Or continue to specify it explicitly.

---

Which means I'm not really sure what you were asking for now, I thought you wanted the default JDK to be 17 for mvn but then above you didn't seem to want that. LMK

Edit: or is that you want the installed version of mvn to use java@17? In which case @dosu is completely right and we could (and should) make it possible to do an install like:

pkgx install +java@17 mvn

I should think

[felipecrs]

Well I mean, you personally, as some kind of configuration.

Oh. Yeah. Well, I like to keep some version of mvn and java available in my PATH, just in case I open some IDE in some unknown repository, and I still can have some kind of support (e.g. the VSCode Java extension requires JDK to be installed and Maven for a few operations).

Of course, the correct version should depend on the repo.

Java 20 is not even an LTS, so my immediate thought was to switch it to some LTS version, that's how I ended up with 17.

---

Which means I'm not really sure what you were asking for now

Ok, let me clarify. What I am really proposing is a way to make the maven installed by pkgx use my system's java.

So that:

1. pkgx install mvn
2. pkgx install java@17
3. at this point, I want mvn to use java@17 because that's my system's default
4. pkgx install java@20
5. now I expect mvn to use java@20

And I totally understand that this doesn't feel logical to how pkgx works today (because mvn declares a dependency on java and therefore pkgx has to manage it).

So, I would like to hear your thoughts on something like this.

PS: I'm not requesting anything. Just trying to open a discussion around it so we can come up with ideas.

---

That said, I think pkgx install +java@17 mvn would be a cool addition as well. Not exactly what I was looking for (i.e. mvn shouldn't have an exclusive version of java to run on, it should just run on any version). But should be useful in several other use cases. For example, if I want to force some tool to use a specific version of Python (pkgx install [email protected] asciinema, even though asciinema depends on python@latest).

[felipecrs]

Or maybe... pkgx could "maintain" some kind of global pkgxenv for pkgx-installed tools. This way, when I pkgx install java@17, it would update java within such global pkgxenv for every pkgx-installed tool that depends on java@*.

Hah, well I was thinking of making a separate tool that can install pkgs properly from the pkgx index. And then putting the existing install command into mash with a better name.

I think that's a great idea.

[mxcl]

K I get what you are asking for.

I think it’s possible that companions could work this way. If we find a system version we use it.

We don’t currently have a way to check for this. We would have to implement something like “iterate the complete list of programs the package.yml provides and check if they exist in the same folder of PATH, if so then this dep is considered satisfied”.

[felipecrs]

Yeah, that sounds great. :)

[felipecrs]

For reference, the only way to make this work ATM is to ensure java before mvn when running for the first time:

# Clean existing cache (important)
$ rm -rf ~/.pkgx

$ pkgx install java@17 mvn@3

# Run java first so that it gets cached
$ java --version
openjdk 17.0.11 2024-04-16
OpenJDK Runtime Environment 1.1.6 (build 17.0.11+0)
OpenJDK 64-Bit Server VM 1.1.6 (build 17.0.11+0, mixed mode, sharing)

# With a cached version of java, mvn will reuse it because it depends on java@*
$ mvn --version
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /home/felipecrs/.pkgx/maven.apache.org/v3.9.6
Java version: 17.0.11, vendor: tea.xyz, runtime: /home/felipecrs/.pkgx/openjdk.org/v17.0.11.4
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.15.146.1-microsoft-standard-wsl2", arch: "amd64", family: "unix"

[felipecrs]

@mxcl one quick way (and maybe even not so bad) around it would be to undeclare java as runtime dependency of maven, and similarly undeclare node as runtime dependency of npm.

For obvious reasons mvn and npm will fail when running without a java and node version, but this can be a good thing (i.e. no implicit dependencies, you should declare yours).