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

Update code.md #36

Merged
merged 4 commits into from
Dec 24, 2020
Merged

Update code.md #36

merged 4 commits into from
Dec 24, 2020

Conversation

odow
Copy link
Member

@odow odow commented Dec 14, 2020

This JuMP issue jump-dev/JuMP.jl#2388 raised the point that we no longer have a way of mentioning JuMP extensions.

@joaquimg
Copy link
Member

The plan is to start with a small list and grow it as users make PRs?
Or we want to invest a little more time in this now?

Should there be a warning saying the some might not be compatible with the latest version o JuMP?
Moreover, they are not necessarily compatible with each other...

Should we do any curating, like a GHA to run the packages with the latest JuMP? Julia had it at some point.
This is linked to the question of whether there should be conditions or not for some package to make into the list.

@odow
Copy link
Member Author

odow commented Dec 15, 2020

I don't think we need to test they work with the latest version of JuMP. It's a list of external packages. However, I think we can keep it pretty tight, packages would need to meet a certain minimum threshold of having docs+tests, etc.

Other candidates would be

  • BilevelJuMP
  • StochasticPrograms
  • Plasmo

List of JuMP dependents https://juliahub.com/ui/Packages/JuMP/DmXqY/0.21.5?t=2

@joaquimg
Copy link
Member

Good idea.
I am in favor of adding some sort of minimum list of requirements. Like tests, docs/examples, being in the Julia main registry also.
I think that we might need to highlight that extensions are usually developed independently of JuMP.

Nice list!
From a quick scan I would consider also:

  • SetProg
  • PiecewiseLinearOpt
  • ParameterJuMP
  • LinearFractional
  • ConstraintSolver

There is also the MOI ones like MOO, QuadraticToBinary, Dualization. These are very useful and could be mentioned.

Any idea about what to do with things like Coluna?

@odow
Copy link
Member Author

odow commented Dec 16, 2020

MOO is experimental and doesn't work. I would prefer Dualization gets moved into MOI as a submodule.

@joaquimg
Copy link
Member

Fair enough, this is a great start!

Dualization as a submodule of MOI looks good.

@blegat
Copy link
Member

blegat commented Dec 16, 2020

Dualization as a submodule of MOI looks good.

In the mean time, it makes sense to add it in the list. The point of having it separate is to have it tested by the users and get feedback so that it matures so highlighting it here is relevant. We can add MOI extensions in a later PR though.

@odow odow merged commit 575344e into master Dec 24, 2020
@odow odow deleted the odow-patch-1 branch December 24, 2020 04:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants