Switch to using Conda binaries

[odow]

Xpress publish binaries on Conda: https://anaconda.org/fico-xpress/xpress/files

They include a community license. If this works, it would greatly simplify things, and we'd be using their official binaries.

Closes #217

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 49.67%. Comparing base (be5e6f3) to head (926a8d9).
Report is 84 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #218      +/-   ##
==========================================
- Coverage   56.64%   49.67%   -6.97%     
==========================================
  Files           9        9              
  Lines        4288     4815     +527     
==========================================
- Hits         2429     2392      -37     
- Misses       1859     2423     +564     

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

[odow]

@joaquim should I add Windows too? You'll probably want to test this with your PSR binaries and license before we merge.

[odow]

Windows support seemed problematic:

But I don't have a local Windows to debug.

[hellemo]

Very nice! FWIW I just did a quick test in Windows, and it seems to work perfectly (as a user, did not test CI).

One caveat is that this is not a pristine system (just renamed my xpress folder), and the license file was found automatically. I suspect this might be from a previous install. What is the recommended way to provide the location of the license file when binaries are provided automatically?

[odow]

I just did a quick test in Windows

Did you use one of the intermediate commits? I removed automatic from the latest commit.

We need to document, but it would be to set the XPAUTH_PATH pointing to the license file

[hellemo]

Weird, now it doesn't work anymore. I think maybe I was relying on the results from a previous Pkg.build for it to work, and switching between this branch and the release version didn't trigger a rebuild.

When I lost contact with the license server, I did a manual build and since then it doesn't work anymore. (the need to rebuild after losing the license server is rather annoying).

[hellemo]

I think I figured it out, I reenabled the artifact for windows, then I get the same permissions error as you mentioned in an earlier comment.
If I also set executable permissions to the library directory, I get it to work as expected:

elseif Sys.iswindows()  # Use the artifact instead.
    const xpressdlpath = joinpath(
        LazyArtifacts.artifact"xpresspy",
        joinpath("Lib", "site-packages", "xpress", "lib"),
    )
    chmod(dirname(xpressdlpath), 0o755; recursive=true) 
    const libxprs = joinpath(xpressdlpath, "xprs.dll")

[odow]

Oh nice! Let me try that

[odow]

Niiiiice.

One thing was talking to @simonbowly about. I wonder if it makes sense to split the binaries into an Xpress_jll.jl package. Then we can version the upstream binaries separately from Xpress.jl.

Otherwise everytime we change the Artifacts.toml it's a potential breaking change to Xpress.jl.

[odow]

See #220

That might take a while to tag and release etc, so we should do this PR first.

That'll let me make some progress on open issues, and we can decide what to do before we tag the next release.

[joaquimg]

I will test here to

[joaquimg]

I am not sure about the consequences of adding the artifacts.

Maybe a weakdep on Xpress_jll?

[odow]

The artifacts are lazy, so they should only be downloaded if you use them.

[odow]

I think ideally, we'd all just use Xpress_jll and Gurobi_jll, and version them appropriately. No more installation issues.

[odow]

@joaquimg can you try this branch? It should use the binaries only if CI is true.

[odow]

Closing in favor of #221