The share library issue could be dealt with by separating library installation in loading into a lower layer from pure Julia packages, and requiring all packages to agree on a version of each library that they can share. This is less of an issue since system libraries tend to be pretty stable.
On Mon, Dec 21, 2015 at 10:07 PM, Jake Rosoman <[email protected]> wrote: > Yea though in that case since it's intentional duplication you would be > able to change the name of the package. > > My issue with the current system is that any package that gets used a lot > develops a responsibility to not change since all packages that depend on > it would be broken until everyone finds the time to update their own > packages. Repeat for that packages dependencies. Being able to run two > versions gives people a grace period to update where everything still > works, be it with more code generated. Or at least thats the dream, I need > to figure out exactly how well it will actually work for Julia considering > the issues Stefan mentioned. > > Another solution to this problem could be to append a version number to > the name of your package when you make you first significant change. > >> On Dec 22 2015, at 2:43 pm, Daniel Carrera <[email protected]> wrote: >> I think there might be some merit in having two versions of a package >> installed (e.g. "experimental vs stable"), but I certainly wouldn't want to >> RUN two versions of the same package at the same time. >> >> Cheers, >> Daniel. >> >> On Sunday, 20 December 2015 17:23:01 UTC+1, Stefan Karpinski wrote: >> >> This seems to be a design based largely on npm. >> >> The idea of modules (and packages) being unnamed internally is appealing, >> largely for the prospect of it being possible to rename packages without >> breaking code that uses them although I'm not certain this is realistic. >> >> I'm not sold on the idea that it makes sense to load multiple versions of >> packages. There are some major issues: >> >> *Generic functions.* What happens when two different versions of a >> package both introduce separate generic function that other packages are >> supposed to share? One of the most confusing situations I see people >> encounter is when they've reloaded some code that defines a type and have a >> generic function that dispatches the old version of that type and they try >> to call the function on the new version of the type. The dispatch doesn't >> work, of course, but it looks like it should. Very confusing. This seems to >> be intentionally introducing a far worse form of that. It's possible that a >> coherent story can be told about how to deal with this, but without that >> story this seems pretty hard to swallow. >> >> *Shared system libraries.* What do you do when two different versions of >> a package want to load different versions of system libraries? In theory >> dlopen can do this but in practice it does not work well at all. JavaScript >> doesn't have to deal with this so npm can just ignore the issue. >> >> *Code generation.* Julia is already a bit of a beast when it comes to >> the amount of code that is generated. This makes that N times worse, for >> some unknown and potentially fairly large N. >> >> On Sun, Dec 20, 2015 at 10:05 AM, Tom Breloff <[email protected]> wrote: >> >> My reaction is the same as Tim Holy's. While I agree there are aspects >> of Julia's modules which are not perfect, it's not clear at all how your >> package changes the workflow. In fact, I don't understand anything about >> your package. Could you please try to write up the design thoughts behind >> what you are doing, so that we can understand the high level concepts that >> you are attempting? >> >> On Sun, Dec 20, 2015 at 6:24 AM, Tim Holy <[email protected]> wrote: >> >> After reading your README example, I'm still left wondering how one works >> with >> Kip, or how it fixes the problems you're describing. To me it's not at all >> obvious how your example "illustrates" the statements you make in the >> prose. >> You might consider explaining the meaning of the various arguments to >> @require, what an "index" file is and what its format should be, and >> exactly >> what the call to the emit function is supposed to demonstrate. >> >> Best, >> --Tim >> >> On Saturday, December 19, 2015 11:26:53 PM Jake Rosoman wrote: >> > I forgot to actually link to the project < >> https://github.com/jkroso/Kip.jl> >> > >> > On Sunday, December 20, 2015 at 8:25:04 PM UTC+13, Jake Rosoman wrote: >> > > Julia's module system is the one part of it I feel confident enough >> to say >> > > is bad. It can't handle several versions of the same package. Is hard >> (or >> > > impossible?) to depend on packages that aren't in the registry and >> hard to >> > > add (controversial) things to the registry. I also find it ugly and >> hard >> > > to >> > > use but now I'm getting into opinions so I'll stop. >> > > >> > > Kip solves all these problems and works fine alongside Julia's current >> > > module system so you can try it out now. I hope that eventually we can >> > > replace Julia's module system if people generally agree that it's >> worth >> > > doing. I've created a poll to measure the communities opinion >> > > <http://tally.tl/3002Y> and you can change your vote at any time so >> feel >> > > free to say no now but follow the discussion. >> >> >> >>
