DIP11: Automatic downloading of libraries

[Nick Sabalausky]

"Adam D. Ruppe" <destructionator at gmail.com> wrote in message 
news:it9ch1$140r$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> You import a module *from* a library.
>
> I don't think libraries, aside from individual modules, should even
> exist in D, since you can and should put all interdependent stuff
> in a single file.
>

Well, even if that's a valid point, the problem still remains that many 
people don't feel that way and many (most?) projects don't work that way. 
Should we just leave those people/projects out in the dark? Your approach, 
on the other hand, can be achieved by making each module a separate library.


>
> You could do the same thing with a library concept, but would you?
> Do you download a whole library just so you can implement a shared
> interface that is otherwise unrelated?
>

Libraries are small and disk space/bandwidth is cheap. And note that that's 
being said by the #1 "old-hardware" guy around here.


>
>> Also, if a library needs any special "setup" step, then this
>> won't even work anyway.
>
> This is true, but I see it as a strike *against* packaged libraries,
> not for it.
>

Even if it's inappropriate for most libraries, such as your example, I do 
think there are good uses for it. But regardless, operating a a per-lib 
basis instead of per-file doesn't *force* us to support such a feature if we 
decided we didn't want it.

>> I think a substantial number of people (*especially* windows
>> users - it's unrealistic to expect windows users to use anything
>> like junctions) would expect to be able to use an already-
>> installed library without special setup
>> for every single project that uses it.
>
> The download program could automatically make locally available
> libs just work without hitting the network too.
>

I'm just opposed to "duplicate every lib in every project that uses it" 
being the default.


>> I think things like apt-get and 0install are very good models for
>> us to follow
>
> Blargh. I often think I'm the last person people should listen
> to when it comes to package management because the topic always
> brings three words to my mind: "shitload of fuck".
>
> I've never seen one that I actually like. I've seen only two
> that I don't hate with the burning passion of 1,000 suns, and
> both of them are pretty minimal (Slackware's old tgz system and
> my build.d. Note: they both suck, just not as much as the
> alternatives)
>
> On the other hand, this is exactly why I jump in these threads.
> There's some small part of me that thinks maybe, just maybe,
> we can be the first to create a system that's not a steaming pile
> of putrid dogmeat.
>
>
> Some specific things I hate about the ones I've used:
>
> 1) What if I want a version that isn't in the repos? Installing
> a piece of software myself almost *always* breaks something since
> the package manager is too stupid to even realize there's a
> potential conflict and just does its own thing.
>
> This was one of biggest problems with Ruby gems when I was forced
> to use it a few years back and it comes up virtually every time
> I have to use yum.
>
> This is why I really like it only downloading a module if it's
> missing. If I put the module in myself, it's knows to not bother
> with it - the compile succeeds, so there's no need to invoke the
> downloader at all.
>
>
> 2) What if I want to keep an old version for one app, but have
> the new version for another? This is one reason why my program
> default to local subdirectories - so there'd be no risk of stepping
> on other apps at all.
>
>
> 3) Can I run it as non-root? CPAN seemed almost decent
> to me until I had to use it on a client's shared host server. It
> failed miserably. (this was 2006, like with gems, maybe they
> fixed it since then.)
>
> If it insists on installing operating system files as a dependency
> to my module, it's evil.
>
>
> 4) Is it going to suddenly stop working if I leave it for a few
> months? It's extremely annoying to me when every command just
> complains about 404 (just run yum update! if it's so easy, why
> doesn't the stupid thing do it itself?).
>
> This is one reason why I really want an immutable repository.
> Append to it if you want, but don't invalidate my slices plz.
>
>
>
> Another one of my big problems with Ruby gems was that it was
> extremely painful to install on other operating systems. At the
> time, installing it on FreeBSD and Solaris wasted way too much
> of my time.
>
> A good package manager should be OS agnostic in installation,
> use, and implementation. It's job is to fetch me some D stuff
> to use. Leave the operating system related stuff to me. I will
> not give it root under any circumstances - a compiler and build
> tool has no legitimate requirement for it.
>
> (btw if it needs root because some user wanted a system wide thing,
> that's ok. Just never *require* it.)

These are all very good points that I think we should definitely keep in 
mind when designing this system. Also, have you looked at 0install? I think 
it may match a lot of what you say you want here (granted I've never 
actually used it). It doesn't require admin to install things, for instance. 
And it keeps different versions of the same lib instead of replacing version 
N with version N+1.

My point about apt-get and 0install being good models for us to follow was 
really referring more to: Ok, I want to install "XYZ", so I tell it to 
install XYZ and the damn thing *just works*, I don't have to fuck around 
with the dependencies myself, the machine does it. I don't have to give a 
shit what requires what, or what version. The damn thing just does it. In 
fact, that was one of the main reasons I gave up on Linux the first time I 
tried it. Installing anything was idiotically convoluted. Despite any 
shortcomings they may have, things like apt-get at least make the situation 
tolerable.