Should primes.jl be moved into its own package?

[ararslan]

This follows a comment from @kmsquire, https://github.com/JuliaLang/julia/pull/16349#issuecomment-219094555. According to @pabloferz, none of the functions defined in primes.jl are used elsewhere in Base, so it would be a pretty clean separation.

Should we go through with this and make a Primes.jl (or whatever) package?

[tkelman]

I'm in favor. I just created a JuliaMathematics organization a few days ago anticipating this kind of thing (and possible migrations of existing packages out of JuliaLang to ease the CI queue as Tim brought up on julia-dev), let me know if you'd like an invite.

[ararslan]

Oooooh, yes please! :D

That's a great idea for a separate organization. Combinatorics.jl could also live there. (Though perhaps we could shorten Mathematics to Math, akin to JuliaStats?)

[pabloferz]

I'd like an invite if it is not too much to ask. Also, I think JuliaMath would be nicer.

[StefanKarpinski]

I like JuliaMath better as well and it matches how other orgs are named better.

[mschauer]

If juliamath gets enough attention this is maybe the best solution. I also volunteer

[mschauer]

PS: An obvious logo would be the julia set, with z^3 to get the analogy to the three dots:

[ararslan]

@mschauer The GitHub reaction emojis don't do my feelings for that logo justice! I love it!

@tkelman It seems like there's a lot of support for branching Primes.jl out. Want to start a Roadmap.jl in the JuliaMath organization and we can start discussing which repos we want to steal adopt from JuliaLang et al.?

[ararslan]

See also #5155

[simonbyrne]

Created: see https://github.com/JuliaMath/Primes.jl

[rfourquet]

[Disclaimer: I don't know anything about packaging] For now, I would prefer for Primes.jl to be moved out of base but still in the main Julia repo, e.g. as a standalone module in a stdlib directory. Having such a directory would make it easy to trim Base without having to create new packages. While the language is not stabilized yet, functions like factor can for example be used to test the performances of BigInt arithmetic operations. (Keeping those modules in stdlib would not help of course in reducing the traffic of Julia's github, if that was one of the goals...).

[JeffBezanson]

I like that idea; it creates a gradual transition that makes the work easier to start and easier to parallelize:

Stage 1: Create directories stdlib/Primes etc. and move pieces of Base there, but they can still be included in the sysimg. This should only be done for bits that we might eventually want to make external packages. It should also involve work to de-couple the module as much as possible.

Stage 2: Remove pieces from the sysimg, but hook up something that makes them easy to load with using.

Step 3: Move some stdlib subdirectories to external packages, maybe some permanently and some to be cloned by default during the build.

[tkelman]

Is creating new packages really all that difficult? Creating actual packages also allows people to use new features and get bugfixes on stable versions of Julia without having to wait for base's release schedule.

[martinholters]

The present situation looks rather unfortunate for packages trying to achieve cross-version compatibility even for Julia 0.3, as Primes requires Julia 0.4. So if package Foo want to call primes, it would have to conditionally require the Primes package depending on Julia version, which the current REQUIRE syntax doesn't allow. (Or did I miss something?) A possible solution could be to have a basically empty version 0.0.1 of externalized packages tagged that would be pulled in by older Julia version that still have the functionality in base, anyway. With @JeffBezanson's proposal, we could postpone this problem (a conditional using being no problem), but once functionality is actually moved to external packages, this needs some consideration.

[simonbyrne]

I didn't think about 0.3 support. The empty v0.0.1 does sound like a good idea though.

[tkelman]

You can kind of do conditional require by having separate branches of the package, one with 0.3 support and one without.

[mschauer]

Moving takes away load from the base language, but at a cost. The farther away something is on the line Base <- Base/stdlib <- JuliaLang/Something <- JuliaDedicatedorg/Something <- Contributor/Something the less attention in detail it receives by the general (julia-)public.

[rfourquet]

Creating a package is not especially difficult, but it requires a deprecation (which is not always trivial) and also some discussion as to whether the community thinks the functionality should go into a package or not. There has been discussions regarding the creation of a "blessed" standard library (in which I would like "Primes" to be), but AFAIK no clear plan has been made. Moving pieces of Base into stdlib modules is not a big commitment (it can be reverted easily). It allows to clarify the interdependencies of those pieces and to defer the decision of moving them into external packages until the overall plan has matured. (@mschauer's comment explains my initial reluctance to remove Primes from Base).

[mschauer]

@rfourquet I would not worry too much though as Primes.jl for now will grow up as spoiled only-child with great staff-children ratio.

[tkelman]

Yes we should get a more formal process in place for doing this "the right way." I think that has to come through practice and doing it several times. There is a cost in number of people who will pay active attention to things that aren't in base or aren't in the main JuliaLang org, but I think the costs of having to be bound by base Julia's release cycle and CI load outweigh those. Participation can happen in any repository, being outside of base allows things to be more focused and less strict.

[simonbyrne]

Closed by #16481, and Primes.jl

[rfourquet]

Don't we want to preserve the git history of moved files (i.e. export the relevant history to the created packages)? This is what was done with julia-emacs for example.

[tkelman]

Bit too late, but if someone wants to do that as a PR rather than rewriting the history that's already been registered in the package then go ahead.