When I say "work well together" I don't just mean that their versions technically work together without errors, but also that they match stylistically and that the datastructures that they expect as input/output match so that no excessive translation and/or copying of data is needed which is bad for performance and style. That kind of discussion is for example happening in OCAML to come to a platform and how to resolve the ocaml standard lib vs Jane street lib schism.
On Monday, August 1, 2016 at 5:19:17 PM UTC+2, Steven Sagaert wrote: > > I think the most important part of it is the idea of having a second > (beyond the standard lib that comes with the runtime) larger, optional > layer of curated libs that are known to work together. That together with > the metapackage idea for easy inclusion ( maybe with possible overrides as > in the Rust proposal) would be very handy for people who do not do Julia > coding all the time and hence cannot follow the larger package ecosystem > closely. People who do not want this second layer could still just use the > standard lib + whatever packages they want. One could even extend this to > multiple layer, each one more optional and lighter curated: standard lib -> > platform light -> extended paltform -> ... > > Now there is already a good attempt in the julia ecosystem to group > related packages in webpages and try to avoid too much libraries that do > the same or partially overlap (more like scientific Python, rather than the > R jungle) and that's great, but per group there still are several > competing packages and sometimes it's unclear from the descriptions to pick > a clear winner. A curated subset of these "the platform" by the community > that adrresses the most common needs except maybe for special niches, would > be very helpful. That's all :) > > On Monday, August 1, 2016 at 4:33:24 PM UTC+2, Stefan Karpinski wrote: >> >> There's a fair amount of discussion of the Rust Platform proposal over >> here: >> >> https://internals.rust-lang.org/t/proposal-the-rust-platform/3745 >> >> In short there's a lack of agreement to this in Rust. Moreover, in Rust, >> different versions of libraries are much more closely locked to each other, >> whereas in Julia the coupling is much looser. Steven, since you're in favor >> of this idea, can you explain why you think it's a good idea for Julia? >> What problems does it solve? >> >> On Mon, Aug 1, 2016 at 7:31 AM, Tony Kelman <[email protected]> wrote: >> >>> The vision I personally have for this would be something more like SUSE >>> Studio (https://susestudio.com/) where it's just a few clicks, or a >>> configuration file in the build system, that could give you a set of >>> default-installed packages of your choosing, and make installers for your >>> own custom "spins" of a Julia-with-packages distribution. >>> >>> >>> >>> On Monday, August 1, 2016 at 2:08:06 AM UTC-7, Tim Holy wrote: >>>> >>>> module MyMetaPackage >>>> >>>> using Reexport >>>> >>>> @reexport using PackageA >>>> @reexport using PackageB >>>> ... >>>> >>>> end >>>> >>>> Best. >>>> --Tim >>>> >>>> On Monday, August 1, 2016 1:48:47 AM CDT Steven Sagaert wrote: >>>> > is more than just a webpage with a list of packages... for starters >>>> the >>>> > concept of metapackage. >>>> > >>>> > On Monday, August 1, 2016 at 10:25:33 AM UTC+2, Tamas Papp wrote: >>>> > > Maybe you already know about it, but there is a curated list of >>>> packages >>>> > > at https://github.com/svaksha/Julia.jl >>>> > > >>>> > > On Mon, Aug 01 2016, Steven Sagaert wrote: >>>> > > > see https://aturon.github.io/blog/2016/07/27/rust-platform/ >>>> >>>> >>>> >>
