is it possible to specify a license file from within Julia?

[ExpandingMan]

So I have a package which uses gurobi which I'm trying to make a lot more portable for containerization purposes, but Gurobi has been a thorn in my side when trying to do this in a number of ways.

It seems like the license file must be specified by GRB_LICENSE_FILE and that this must happen in the shell. This makes it impossible for me to build a truly portable container, because it would need to have different license files in different contexts.

It doesn't seem like the Gurobi API exposes this selection, but I thought I'd ask, is there any way of doing this?

[odow]

The real issue you have is the need to generate the license via grbgetkey, which ties the license to a particular host.

Does setting GRB_LICENSE_FILE via ENV["GRB_LICENSE_FILE"] = " ... " before you run using Gurobi not work?

[ExpandingMan]

My plan was to keep all licenses with my package and then have it select them depending on the host. This would allow me to, e.g. deploy docker images at different locatiosn (where gurobi is allowed to run by virtue of the licenses) seamlessly. Gurobi is really not cooperating with my trying to do this, as I also wanted to set GUROBI_HOME via Julia Pkg artifacts, but the check for GUROBI_HOME during the build step of this package seems to preclude that.

Ideally, the thing I most want is to be able to do a ]add SomePackage (from a private repo, of course) from any docker container where gurobi is allowed to run and have it "just work", but gurobi is presenting lots of obstacles to this.

[odow]

Feel free to modify the build.jl.

but gurobi is presenting lots of obstacles to this.

I think this is by design.

I take it there is a limited number of places this is going to be deployed to? Couldn't you just figure out where the default license file location is, then copy the gurobi.lic file to that location on install.

[ExpandingMan]

Yeah, what you're saying is certainly doable, I'm able to get portable containers but gurobi is mostly preventing me from making a truly portable package. This isn't the end of the world, but complicates the environment build process (I have multiple containers across multiple projects).

Ok, not sure there is anything to be done here, but I may make a PR to modify the build.jl to make things a little easier if I can think of a way of doing that without breaking anything.

[mlubin]

This likely isn't a new request for Gurobi. I'd recommend contacting them directly.

[ExpandingMan]

Yeah, my company has a lot of licenses with them, so we get their attention, I may re-open this conversation if I get too aggravated.

We've had discussions about these sorts of IT issues with them in the past, but they weren't particularly helpful (even though, as you said, it was clear we weren't the only people they were hearing this from). It's gotten bad enough that my colleagues and I have semi-seriously considered starting to look for Gurobi alternatives, even though Gurobi itself is obviously fantastic as a solver.

My hope was that eventually they'd realize that all of their clients are doing "microservices" and need to make things easily portable and containerizable, and their current setup is a big obstacle to that, so they'd move toward trying to make things easier, but I don't think anything has changed in the last few years.

There's also the related issue that the current system strongly incentivizes using "compute servers". All of this has been a nightmare for trying to set up proper test environments, or even to do a staged upgrade of Gurobi binaries.

TL;DR: Gurobi: fantastic solver, terrible for IT issues.

[odow]

Closing since this is not a Gurobi.jl issue. Please re-open if there is any movement upstream.