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](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. >>> >>> >> >>
