DIP11: Automatic downloading of libraries

[Daniel Gibson]

Am 14.06.2011 17:20, schrieb Bernard Helyer:
> We just had a discussion with Andrei on IRC. Logs follow:
> 
> <andralex> bernardh: destroy
> <andralex> so I can cry
> <bernardh> This could be handled by an external tool, which would not 
> increase the burden on the language and implementation. 
> <bernardh> Because suddenly you've added networking to the compiler, 
> which is fine, but it better be worth it. 
> <bernardh> And really what you add to the language isn't worth it.
> <bernardh> A pragma that says you can fetch it from that?
> <bernardh> A build tool could do that. 
> <bernardh> No need for that to be encoded in the source.
> <bernardh> andralex, tl;dr - you don't add enough semantics to justify 
> adding this to the compiler
> <andralex> bernardh: well
> <andralex> the advantage is that the barrier of entry for sharing code 
> and using shared code is lowered
> <andralex> just paste one line and you're ready to go
> <bernardh> Yeah, but most projects use a build tool.
> <bernardh> So that _still_ has to be set up.
> <bernardh> That's non-zero.
> <bernardh> If you add the capability to that tool.
> <bernardh> The increase is identical to that if you added it the compiler.
> <bernardh> Besides which, URLs to libraries seems better in build scripts 
> than the source itself.
> <bernardh> andralex, _and_ that cuts down on modifications to the 
> compiler (you're proposing a change to the link behaviour in that case). 
> <bernardh> So my point remains. 
> <bernardh> You add burden to the language and the implementation for no 
> gain.
> <andralex> hm
> <andralex> well I mentioned to walter that rdmd could take care of that
> <andralex> he wanted it to be in dmd
> <andralex> his point is this:
> <andralex> say I'm John Smith and I wrote some cool D code
> <andralex> how do you try it?
> <andralex> well it depends on some libs
> <andralex> so you need to download John's code and those libs
> <andralex> put them somewhere
> <andralex> then build accordingly
> <andralex> this proposal cuts through all that red tape
> <bernardh> You didn't respond to me at all. 
> <andralex> ?
> <andralex> You mentioned no gain
> <bernardh> The build tool could refer to scripts and then the 
> dependencies would be automatically set up just the same.
> <andralex> I just told you where the gain is
> <bernardh> ^ 
> <andralex> who writes the scripts?
> <bernardh> Library writers. 
> <Suprano> ME
> * wilsonkk has quit (Remote host closed the connection)
> <andralex> exactly
> * Joseph_ has quit (Ping timeout: 276 seconds)
> <bernardh> What's your point?
> <andralex> so everyone will choose their own paths, their own 
> conventions, their own dependency setup
> <bernardh> The simplest form for John
> <bernardh> No, because the conventions would be set by the tool.
> <mleise> I can understand both your points of view well. This feature 
> fits with dmds other built-in capabilities: ddoc, profiler, code 
> coverage, ... . Then again it is something you expect to be done once by 
> built tools (like Maven) and it adds some non-determinism to the compiler.
> <Nekuromento_work> I think it complicates things more than it helps
> <Nekuromento_work> where dmd will fetch the code?
> <Nekuromento_work> how can dmd interact with code that needs custom build 
> sctips
> <Nekuromento_work> what happens if several of my projects use one 
> library? will dmd keep one copy for each?
> <Nekuromento_work> what happens if I use different versions?
> <Nekuromento_work> etc.
> <bernardh> The end result for the user would be the same .
> <bernardh> Paste url in file.
> <bernardh> Use code. 
> <bernardh> Happy. 
> <Nekuromento_work> the point is, It's not compiler's responsibility 
> <andralex> Nekuromento_work: why not?
> <andralex> I mean I don't see a strong reason why not
> <bernardh> andralex, because the compiler does no other build work
> <andralex> hm
> <bernardh> andralex, the build tool WOULD STILL BE REQUIRED, unless DMD 
> does a whole lot more
> <andralex> well I need to go; at best we should discuss in the newsgroup 
> so there's an archive
> <bernardh> So adding it to the compiler would only move it.
> <bernardh> Unless the DIP is improved, I for one won't implement it. 
> <andralex> bernardh: the problem with having a build tool is that it 
> requires additional files
> <bernardh> Waste of time in its current form.
> <andralex> config, etc.
> * wilsonkk (~kvirc at S0106001b11030a92.cg.shawcable.net) has joined #d
> <andralex> with this it's all included in the source
> <andralex> where it belongs
> <bernardh> Yes but it's STILL REQUIRED
> <bernardh> You haven't removed the build tool
> <bernardh> only one aspect
> <andralex> right
> <andralex> agreed
> <bernardh> So without more support, it's a useless addition. 
> <bernardh> That's my opinion, in the end.

<andralex> bernardh: the problem with having a build tool is that it
requires additional files

One additional file. I don't think having one file would be a burden to
the programmer, not much more than adding pragmas in his code.

But if there's central metadata repository even this additional file
isn't needed - neither are pragmas - (the build-tool will ask that repo
where to find the lib/module), unless the lib is kind of obscure or
brand-new and thus not known by the metadata repo. And in that case:
it's just a single file.

(Of course it would be possible to periodically or via "build-tool
update" - like apt-get update - fetch the metadata, so the server
doesn't have to be asked each time.)

Cheers,
- Daniel