Use Xpress_jll for binaries

[odow]

Alternative to #218

• Wait for FICO to okay

If we like this, and once the kinks are sorted, I'll move https://github.com/odow/Xpress_jll.jl to JuMP.

[codecov]

Codecov Report

Attention: Patch coverage is 66.66667% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 67.91%. Comparing base (82fe624) to head (0c7664b).

Files	Patch %	Lines
src/Xpress.jl	60.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #220      +/-   ##
==========================================
- Coverage   68.13%   67.91%   -0.22%     
==========================================
  Files           6        6              
  Lines        3295     3301       +6     
==========================================
- Hits         2245     2242       -3     
- Misses       1050     1059       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[odow]

Making progress with Gurobi too: jump-dev/Gurobi.jl#545

[odow]

I'm talking to FICO privately about this.

[odow]

So I wonder about

import Xpress_jll
ENV["XPRESS_JL_LIBRARY"] = Xpress_jll.libxprs
using Xpress

Then we don't automatically install the binaries for people who already have one, and we can clearly document the license conditions that come with Xpress_jll.

[odow]

Xpress are okay with this.

I'll register Xpress_jll, and then we can tweak this with documentation, etc.

JuliaRegistries/General#103121

[joaquimg]

This broke some of our code.
We will have to double check what happened.

[odow]

On the current commit? I guess I need to refine the check for "is this Xpress.jl's CI."

[odow]

There will be a conflict with #251, so we should merge that one first.

[joaquimg]

I think this PR would enjoy some comments on the readme about:

• Default xpress (its limitations: community lic is limited)
• how to use other versions from jll
• how to use local versions

[odow]

So new new problem. The community license for 8.13.4 has expired

[joaquimg]

Can you add the latest community lic to the 8.13 jll?

[odow]

No, we can't modify the JLLs. I think it's fairly reasonable from FICO's point of view: they want people using older versions to upgrade. And if they're using the community license for more than one year...then pay for support.

For "our" license, I've just added the most recent, and we can manually update the secret.

[joaquimg]

I am not sure this is exactly on purpose or just lazyness from FICO perspective.
I wonder if we should have two differente artifacts, one for license and one for the rest.
This would also match well with the fact that the user need their own license but dont need to get into the trouble of getting binaries.

[odow]

I think it's purposeful on FICO's behalf. And we won't be modifying their artifacts, or providing a separate mechanism for users to obtain licenses.

Our options are:

1. Store a community license in a secret that we periodically update
2. Rely on the latest version of Xpress_jll having a valid license that we grab from on install

This PR currently does (2), but I also tried (1). I'm ambivalent, but (2) is simpler for now. It'll also force me to keep Xpress_jll updated.

[joaquimg]

I think we can ask FICO to check.

If a separate artifact for licenses is really not doable, then I think we could go for 2 and document in the readme how a user can do it...

[odow]

then I think we could go for 2 and document in the readme how a user can do it...

We document how to use Xpress_jll here:
https://github.com/jump-dev/Xpress.jl/tree/od/xpress-jll?tab=readme-ov-file#use-with-xpress_jll

I am not going to document how people can get a community license to use 8.x.y by grabbing one from a newer JLL. We can do it in the GitHub action, but it won't be documented.

We can, at most, document what is done for Python: https://anaconda.org/fico-xpress/xpress

[joaquimg]

We document how to use Xpress_jll here: https://github.com/jump-dev/Xpress.jl/tree/od/xpress-jll?tab=readme-ov-file#use-with-xpress_jll

This looks good.

I am not going to document how people can get a community license to use 8.x.y by grabbing one from a newer JLL. We can do it in the GitHub action, but it won't be documented.

We can, at most, document what is done for Python: https://anaconda.org/fico-xpress/xpress

Forcing people to use always the latest version is a source of non-reproducibility.
They can't even go back to compare at some point.
Unless they dig down on how things are automatically downloaded and test newer lics with old libs.

The python thing bad with such lic problem.

But we can keep complexity low and just warn the user that community lic expires and they might be fine grabbing a newer one and using with an old binary.

[odow]

They can't even go back to compare at some point.
The python thing bad with such lic problem.

Oh, I'm well aware, and I agree.

But FICO are saying that they have released a community license where people get to use vX.Y for a period of 12 months. That seems like a reasonable position, even if it means that someone cannot go back and reproduce old code. (They of course can, provided they have a license.)

[joaquimg]

I still think the lic thing is a lazyness/"keep it simple" procedure than any particular enforcement.

However, lets leave this for the future. This PR is great as is.