"Also, there's a good reason to ask "why fuss with distributions when anyone could just add the packages and add the import statements to their .juliarc?" (though its target audience is for people who don't know details like the .juliarc, but also want Julia to work seamlessly like MATLAB)."
I feel like if you're using MATLAB, it should be a really small step to teach about the .juliarc file, as oppose to the amount of maintenance/fragmentation that comes along with multiple distributions. Point #1 makes sense for me, if only because that's a use case that can't be accomplished through simple textfile manipulation On Tuesday, September 13, 2016 at 4:39:15 AM UTC-4, Chris Rackauckas wrote: > > I think one major point of contention when talking about what should be > included in Base due to competing factors: > > > 1. Some people would like a "lean Base" for things like embedded > installs or other low memory applications > 2. Some people want a MATLAB-like "bells and whistles" approach. This > way all the functions they use are just there: no extra packages to > find/import. > 3. Some people like having things in Base because it "standardizes" > things. > 4. Putting things in Base constrains their release schedule. > 5. Putting things in packages outside of JuliaLang helps free up > Travis. > > > The last two concerns have been why things like JuliaMath have sprung up > to move things out of Base. However, I think there is some credibility to > having some form of standardization. I think this can be achieved through > some kind of standard library. This would entail a set of packages which > are installed when Julia is installed, and a set of packages which add > their using statement to the .juliarc. To most users this would be > seamless: they would install automatically, and every time you open Julia, > they would import automatically. There are a few issues there: > > > 1. This wouldn't work with building from source. This idea works > better for binaries (this is no biggie since these users are likely more > experienced anyways) > 2. Julia would have to pick winners and losers. > > That second part is big: what goes into the standard library? Would all of > the MATLAB functions like linspace, find, etc. go there? Would the sparse > matrix library be included? > > I think one way to circumvent the second issue would be to allow for Julia > Distributions. A distribution would be defined by: > > > 1. A Julia version > 2. A List of packages to install (with versions?) > 3. A build script > 4. A .juliarc > > The ideal would be for one to be able to make an executable from those > parts which would install the Julia version with the specified packages, > build the packages (and maybe modify some environment variables / > defaults), and add a .juliarc that would automatically import some packages > / maybe define some constants or checkout branches. JuliaLang could then > provide a lean distribution and a "standard distribution" where the > standard distribution is a more curated library which people can fight > about, but it's not as big of a deal if anyone can make their own. This has > many upsides: > > > 1. Julia wouldn't have to come with what you don't want. > 2. Other than some edge cases where the advantages of Base come into > play (I don't know of a good example, but I know there are some things > which can't be defined outside of Base really well, like BigFloats? I'm > not > the expert on this.), most things could spawn out to packages without the > standard user ever noticing. > 3. There would still be a large set of standard functions you can > assume most people will have. > 4. You can share Julia setups: for example, with my lab I would share > a distribution that would have all of the JuliaDiffEq packages installed, > along with Plots.jl and some backends, so that way it would be "in the box > solve differential equations and plot" setup like what MATLAB provides. I > could pick packages/versions that I know work well together, > and guarantee their install will work. > 5. You could write tutorials / run workshops which use a distribution, > knowing that a given set of packages will be available. > 6. Anyone could make their setup match yours by looking at the > distribution setup scripts (maybe just make a base function which runs > that > install since it would all be in Julia). This would be nice for some work > in progress projects which require checking out master on 3 different > packages, and getting some weird branch for another 5. I would give you a > succinct and standardized way to specify an install to get there. > > > Side notes: > > [An interesting distribution would be that JuliaGPU could provide a full > distribution for which CUDAnative works (since it requires a different > Julia install)] > > [A "Data Science Distribution" would be a cool idea: you'd never want to > include all of the plotting and statistical things inside of Base, but > someone pointing out what all of the "good" packages are that play nice > with each other would be very helpful.] > > [What if the build script could specify a library path, so that way it can > install a setup which doesn't interfere with a standard Julia install?] > > This is not without downsides. Indeed, one place where you can look is > Python. Python has distributions, but one problem with them is that > packages don't tend to play nice with all distributions. This leads to > fragmenting in the package sphere. Also, since it's not explicit on where > the packages come from, it may be harder to find documentation (however, > maybe Documenter.jl automatically adding links to the documentation in > docstrings could fix this?). Also, there's a good reason to ask "why fuss > with distributions when anyone could just add the packages and add the > import statements to their .juliarc?" (though its target audience is for > people who don't know details like the .juliarc, but also want Julia to > work seamlessly like MATLAB). > > This could be a terrible idea, I don't know. But sharing an idea with the > internet is a great way to find out. But I think at least the idea is a > step in the right direction, if not in details. >
