I happen to really like Julia's package manager. It unifies package
development with package usage and is also really convenient to work
with. Because of this I pretty much create a package for every
experiment I make. Personally I'd go around telling colleagues that
Julia's Package Manager is a great tool for reproducible research. So I
actually happen to think it is one of the best features of the language.
The only thing I could think of that would be a great change/addition is
a decent strategy for handling Github-dependencies that are not in METADATA
On 2015-12-20 21:11, Jake Rosoman wrote:
JavaScript doesn't have to deal with this so npm can just ignore
the issue.
It actually does have to deal with this issue but I'm not sure how it
does it
On Monday, December 21, 2015 at 5:23:01 AM UTC+13, 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]
<javascript:>> 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]
<javascript:>> 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.
