Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

List of packages yet to adopt artifacts #653

Closed
ViralBShah opened this issue Mar 25, 2020 · 22 comments
Closed

List of packages yet to adopt artifacts #653

ViralBShah opened this issue Mar 25, 2020 · 22 comments
Labels
builder request 🙏 Request for a new builder long shot 🏹 This is going to be fun

Comments

@ViralBShah
Copy link
Member

ViralBShah commented Mar 25, 2020

This is based on a script @pfitzseb wrote. These are packages that do not use jll packages in 1.3+, but depend on BinaryProvider. This does not include packages that use their own binary download mechanisms.

Must have group

Nice to have

@ViralBShah
Copy link
Member Author

ViralBShah commented Mar 25, 2020

This list is not perfect, and includes

  1. Stdlibs that will become JLLs
  2. Use JLLs on master but need a release
  3. Still have BinaryProvider in project file but don't actually use it
  4. Actually still depend on BinaryProvider on master
  5. Depends on BinaryProvider to support Julia versions older than 1.2
  6. Work in progress packages that are being prepared for artifacts

Also, some packages are more widely used than others. I have split the list into "must have" and "nice to have", but of course, I don't have a strong view on it. Happy to move things around further.

@giordano giordano added builder request 🙏 Request for a new builder long shot 🏹 This is going to be fun labels Mar 25, 2020
@j-fu
Copy link
Contributor

j-fu commented Mar 26, 2020

Hi, Triangulate.jl is ready for it, but how to organize things to keep supporting Julia 1.0 ? Would also care about TetGen if time permits.

@ViralBShah
Copy link
Member Author

Many packages have moved to 1.3+ so that they only support artifacts. I think in the spirit of moving forward, that is the right thing to do.

@ViralBShah
Copy link
Member Author

ViralBShah commented Mar 28, 2020

@mlubin Is there an effort for moving the various solvers that JuMP users towards artifacts?

@odow
Copy link
Contributor

odow commented Mar 28, 2020

The COIN solvers Cbc, Clp, and Ipopt have exceedingly complicated build systems (#509). I have no estimate for how much work is required to make it work. @juan-pablo-vielma managed to make the current binary builders work only after hours and hours of trial and error, and packaging everything up into one giant binary.

Is this a "would be nice to use jll's" or will the current binary builder implementations stop working on a future 1.x release?!?

GLPK is probably not too hard. I'll take a look.

@giordano
Copy link
Member

Let's continue the discussion about Clp in #509, no need to clutter this issue

@mlubin
Copy link

mlubin commented Mar 28, 2020

@ViralBShah The answer appears to be no, there isn't currently an effort. Is BinaryBuilder being deprecated?

@giordano
Copy link
Member

giordano commented Mar 28, 2020

is BinaryBuilder being deprecated?

BinaryProvider, not BinaryBuilder: https://julialang.org/blog/2019/11/artifacts/

@ViralBShah
Copy link
Member Author

@StefanKarpinski Bringing this list to your notice.

@SimonDanisch
Copy link
Member

Could we try to semi automatically move some of these to Yggdrasil? E.g. look up the binarybuilder URL from the deps.jl, download the the build_tarballs.jl and add it to the correct folder?

@ViralBShah
Copy link
Member Author

ViralBShah commented Apr 1, 2020

Could we try to semi automatically move some of these to Yggdrasil? E.g. look up the binarybuilder URL from the deps.jl, download the the build_tarballs.jl and add it to the correct folder?

I've done that process manually in many cases. Given that there's only probably about 30 more such packages, perhaps not worth implementing tooling.

@jaakkor2
Copy link
Contributor

Since MathOptInterface depends on JSONSchema, I would re-classify JSONSchema from "nice to have" to "must have".

@odow
Copy link
Contributor

odow commented Apr 13, 2020

JSONSchema doesn't actually use BinaryProvider to for binaries. It is just used to download files in a test. @fredo-dedup isn't very active on Github, but I have commit access, and was in the process of tidying up the tests: fredo-dedup/JSONSchema.jl#13. I should remove the dependency on BinaryProvider while I'm at it.

Edit: dependency removed in that PR. JSONSchema can be removed from the list above.

@ViralBShah
Copy link
Member Author

Enough of the commonly used packages are done, that I feel we can close this issue.

@aviks
Copy link
Contributor

aviks commented Jun 4, 2020

Some more updates. PRs for:

LIBSVM
LIBLINEAR
NNlib
Hwloc
Gumbo
LibCURL
GoogleCodeSearch
CodecXz

@ViralBShah
Copy link
Member Author

Updated that in the list above.

@aviks
Copy link
Contributor

aviks commented Jun 4, 2020

NLOpt is also done

@ViralBShah
Copy link
Member Author

ViralBShah commented Jun 4, 2020

Filed JuliaStrings/StringEncodings.jl#36 for StringEncodings.jl. Should be straighforward to update the package.

@ViralBShah
Copy link
Member Author

I believe TextAnalysis and StringAnalysis both need libstemmer.

@aviks
Copy link
Contributor

aviks commented Jun 8, 2020

Mongoc is done.

@ViralBShah
Copy link
Member Author

The big missing one now is GR, which has a dependency on QT.

@ViralBShah
Copy link
Member Author

GR is done now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
builder request 🙏 Request for a new builder long shot 🏹 This is going to be fun
Projects
None yet
Development

No branches or pull requests

8 participants