Organization for managing interoperability packages?

[Alex Arslan]

Hello all!

Would there be interest in a GitHub organization that could house repositories relating to interoperability with other languages and software, like a "JuliaInterop"? For example, the organization could be a good place for PyCall, pyjulia, RCall, maybe Keno's Cxx, maybe AppleAccelerate, and others. If people think it would be useful then I can start one. I don't know how many organizations people actually want or actually make sense.

Anyway, it's just a thought.

-Alex

[Isaiah Norton]

This has come up a few times I think; here's one:

https://github.com/aviks/JavaCall.jl/issues/26

I agree with Avik there.

The point of organizations is, IMHO, primarily to group together packages and shared responsibility (i.e. commit rights) for people with a commonality of interest. I don't think that criteria applies well to interop because of limited contributor overlap.

There's a nice advertising benefit too, but I think better solutions exist.

[Alex Arslan]

Hi Isaiah,

Thanks for your reply! That's funny that Mike came up with the same name.

I guess I've misunderstood the point of organizations. I thought they were for grouping together high quality, similarly themed packages so that people know where to look for that stuff. I guess we should scrap the JuliaInterop idea then for the reasons you mentioned.

Anyway, thanks for your input, I appreciate it!

-Alex

[Tony Kelman]

I don't think this is a bad idea. Though many of these are not currently under JuliaLang, they're under individual accounts (the primary author's) or JuliaStats in the case of RCall. It might be good to move IJulia, pyjulia, and maybe a few others out of JuliaLang for CI queue reasons, but the rest are pretty healthy where they are for now. The really important thing for any repo that's under anyone's personal account is that at least one other person (preferably more) are given commit access, in case the maintainer disappears. Granted we can work around that by redirecting metadata to forks as we recently had to do with Showoff.jl, but spreading commit access out a bit helps reduce the chances of needing to do that.

[Stefan Karpinski]

"In case the maintainer disappears" sounds dramatic, but it could be a vacation or just deciding to take the weekend off when something happens to need fixing somewhat urgently. It's also helpful to spread the responsibility to avoid burnout.

[Páll Haraldsson]

On Wednesday, May 18, 2016 at 9:13:35 PM UTC, Isaiah wrote:

This has come up a few times I think; here's one:

https://github.com/aviks/JavaCall.jl/issues/26

I agree with Avik there.

The point of organizations is, IMHO, primarily to group together packages and shared responsibility (i.e. commit rights) for people with a commonality of interest. I don't think that criteria applies well to interop because of limited contributor overlap.

There might be limited contributor overlap, but are there not similar technical issues, to talk about, if not share code? There seem to be, at least to me in three classes of languages:

A.
Languages with memory management, such as C/C++ and Rust, that seems easiest to support. Generally non-VM.

B.
Languages with reference counting (and possibly full GC on top, as in), such as Python, at least CPython. Any with only RC?

C.
Languages with tracing garbage collection (note, CPython fits here and in B, while Jython only in C.), such as Go. And Java.


There are also other divisions, such as languages in a VM, Java, JavaScript, that force a separate process [and ZMQ, may be more appropriate then].

There are common issues with the . operator (that is not yet overloaded), for traditional OO languages.

Dropbox' Pyson JIT Python was in cat. C. but as of 0.5 is in B.:

https://blog.pyston.org/2016/05/25/pyston-0-5-released/

[D language is a special case, as it has GC, but it's also optional (as with Julia); while their optional support, seems more developed.]


Maybe the languages are dissimilar enough, that code can't be shared, but I'm not convinced, people can't help each other.

There's a nice advertising benefit too, but I think better solutions exist.

What solutions? I liked the idea of having them grouped together [somewhere], to at least inform people of these possibilities.