Transfer to JuliaSparse

[ViralBShah]

@lruthotto Would you be ok to transfer the package to JuliaSparse?

[ViralBShah]

I have also sent you an invitation to join JuliaSparse.

[lruthotto]

Sure, I'm happy to do it!

[ViralBShah]

Thanks!

[tkelman]

Unless @lruthotto has gotten approval from the authors of Metis (he has, sorry, didn't know that at the time I wrote this) , this package is violating Metis' license. https://github.com/JuliaSparse/MUMPS.jl/blob/9f28f5e49a19fd8cf9fd9ad0f280c4b576b981de/src/metis-4.0.3/LICENSE#L3-L7

[lruthotto]

I asked George Karypis by email for permission to include the source code of metis v.4.0.3 and he agreed. Shall I put the email here somewhere?

[tkelman]

Oh, great. Yeah that would be good to spell out. And this package itself needs a license.

[lruthotto]

where do you want me to put the email? I'm happy with MIT license for this package. What do you think?

[tkelman]

As a note in the license file, or under src or src/metis-4.0.3 would be good. If we're building the Metis functionality by default here, I think the academic restriction of Metis 4's license should even be spelled out explicitly in the README.

Metis 5.x has a much more standard Apache 2.0 license. I'm told that Mumps 5.0 should be coming out relatively soon, which should be compatible with Metis 5.x. Once that's available, it would probably be best to manage the Metis 5.x bindings in the separate Metis.jl package, and have the Mumps.jl Julia package (optionally maybe?) depend on Metis.jl to handle installation of the Metis library.

[lruthotto]

I updated the description and added a pdf of the email. I think we are fine until MUMPS 5.0 comes out.

[ViralBShah]

Yes, when 5.0 comes out, let's do a bunch of work to make our MUMPS support better.

[lruthotto]

Sounds great. I've just seen that @dpo has done significant work on his MUMPS interface, which seems to be much more advanced than what we've done here.

[dpo]

My current MUMPS.jl interface works with MPI.jl and uses a very simple C wrapper, no Fortran. I'd be very happy to join efforts and move this to JuliaSparse. I'm currently battling silly details to make it work in Linux. The whole thing is based on Homebrew, so if we can get the MUMPS bottles into Homebrew.jl, it should be a breeze to install and use.

[tkelman]

We should not be using homebrew on linux, we should use BinDeps like virtually every other Julia package with binary dependencies. If linuxbrew were standard, mature, and widely used (and if ruby were installed by default on more distributions) I'd have a different viewpoint here, but it isn't.

Even C wrappers are not great - best-practices packages should avoid them. Can we please leave the C and Fortran in the C and Fortran libraries, and write Julia bindings using only Julia code? What are C wrappers necessary for here that couldn't be accomplished with equivalent ccalls?

[tkelman]

And thanks @lruthotto for clarifying the license situation, I think we're okay now.

[dpo]

For one, MUMPS is typically not built as a shared lib. The brew formula does build a shared lib for OSX and Linux (I'm not sure whether debs supply static or shared libs). In addition, I find the C wrapper far easier to understand and maintain than a Julia file that tries to mirror the MUMPS struct. And finally, a thin C wrapper makes it easier to interface MUMPS with other high-level languages, which I think is of interest. Also, when MUMPS 5.0 comes along, I imagine at least some parts of it might be in Fortran 95+, which is more difficult to ccall into.

[tkelman]

The right place for fixing all of these issues is upstream. Build fixes for shared libraries, sane C-callable API's that all high-level languages can interface, etc. don't belong in a Julia package. As I mentioned somewhere else, COIN-OR has been maintaining a build harness (just for dual-precision and serial) to deal with shared libraries, cross-compiling, and hooking into their larger autotools setup for something like 8 years now. It blows my mind that this is an acceptable status quo for any library author. I get that they've got other things to worry about, but any chance of them accepting patches ever? Convincing them to use some form of public version control would also help.

[tkelman]

Sorry for the rant here @dpo, I know this isn't your fault. It's the exact same situation with SuiteSparse, it was the same with AMPL until they hired Victor and moved to cmake and github, it would probably be similar with the HSL libraries if they had a redistributable license and were more widely used.

You're right that a C-Mumps wrapper would probably be useful with Python, or Go, Haskell, whatever else. But in order to avoid repeating the same mistakes the Python community has made over the years making extensions extremely difficult to compile (and hence install and use) cross-platform, it would be best to separate such wrappers from the Julia package. If upstream won't consider patches, do it in an independent C wrapper, in its own repository with its own versioning and a proper build system, that can be reliably packaged and distributed in binary form in the same way as for any other C library.