Am 14.06.2011 16:39, schrieb Adam D. Ruppe:
>> 1) It hard-codes URLs in source code.
> 
> This one is fairly easy to handle - use an http "Moved Permanently" redirect to the new location at the old url.

Is this possible with plain webspace, i.e. when you don't control the
server?
And it's certainly not possible when you're using sourceforge, github
etc and they decide to change their URLs without setting redirects.

On 6/14/11 9:45 AM, Michel Fortin wrote:
> On 2011-06-14 09:53:16 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> said:
>
>> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
>
> I disagree about the model where you specify URLs in source code.

Why?

> I'd suggest an alternative solution: If DMD finds a dmd.conf file at the
> root of one of the -I directories, it uses the download parameters in
> that file to download to populate the directory with modules as needed.
> This would also apply to the current directory. The content of that
> dmd.conf file could look like this:
>
> [module-download]
> package.* = http://someserver.net/d-repo/latest/
> otherpack.* = http://otherserver.net/d-repo/1.2/
>
> That way it's easy to understand what comes from where without having to
> scan all your source code for pragmas.

I agree this would be good to have, but not exclusively. The problem is that anyone who wants to share some code must require potential users to modify their config files, instead of offering them a key-ready solution.


Andrei

Am 14.06.2011 16:49, schrieb Andrei Alexandrescu:
> On 6/14/11 9:35 AM, Daniel Gibson wrote:
>> Am 14.06.2011 16:09, schrieb Vladimir Panteleev:
>>> On Tue, 14 Jun 2011 16:53:16 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>  wrote:
>>>
>>>> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
>>>
>>> Why this is a bad idea:
>>> 1) It hard-codes URLs in source code. Projects often move to other
>>> code-hosting services. PHP, Python, Perl, not sure about Ruby all have a
>>> central website which stores package metadata.
>>> 2) It requires that the raw source code be available via HTTP. Not all
>>> code hosting services allow this. GitHub will redirect all HTTP requests
>>> to HTTPS.
>>
>> It should support HTTPS anyway, to prevent DNS spoofing attacks and such (i.e. most attacks that don't need your own machine to be compromised). But maybe additional support for signing the code would be even better, to be able to detect compromised code on the server.
> 
> Yah, I thought of a SHA1 optional parameter:
> 
> pragma(liburl, mylib, "myurl", "mysha1");
> 

With the SHA1 containing the mylibs hash?
That doesn't help much.. if you don't expect the file to change at all
on the server, you can just bundle it with your source.
One great advantage of being able to download code you're depending on
is that the author can bugfix it and you can can easily update, isn't it?

I thought about letting the author sign his code with GPG, e.g. having a file on the server with signed SHA1 hashes of the files or something like that.

>>> 3) It only solves the problem for D modules, but not any other possible dependencies.
>>>
>>> I understand that this is a very urgent problem, but my opinion is that this half-arsed solution will only delay implementing and cause migration problems to a real solution, which should be able to handle svn/hg/git checkout, proper packages with custom build scripts, versioning, miscellaneous dependencies, publishing, etc.
>>>
>>
>> I personally think that a standard build tool that does this (and
>> possibly also ships with DMD) would be better than support directly in
>> the language.
>> Especially the case that the projects website changes could be handled
>> more easily by adjusting the URL in a config file instead of changing
>> your code.
> 
> This is still possible with D config files that contain pragmas.
> 

OK.
Still, I prefer a build-tool solution. I think that would be easier to
expand to support git etc.

> 
> Andrei

Cheers,
- Daniel

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@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.

To add an editorial note, I feel that this DIP misses the problem. D needs a build tool to be used effectively. This addresses _an_ aspect, but not the whole thing. I think a 'Digital Mars build tool' that was shipped with DMD would be a far more valuable and effective thing to put this and a whole lot more than bolting things onto the language.

On Tue, 14 Jun 2011 15:25:08 +0000, Bernard Helyer wrote:

> To add an editorial note, I feel that this DIP misses the problem. D needs a build tool to be used effectively. This addresses _an_ aspect, but not the whole thing. I think a 'Digital Mars build tool' that was shipped with DMD would be a far more valuable and effective thing to put this and a whole lot more than bolting things onto the language.

This was intended for my post with the IRC logs.

On Tue, 14 Jun 2011 08:53:16 -0500, Andrei Alexandrescu wrote:

> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
> 
> Destroy.
> 
> 
> Andrei

What's the expected payload format? A text/plain D source-file? A zip or tar archive?

If an archive, what's the required directory layout? Should "dsource.foo.baz" be required to be in "/dsource/foo/baz.d" within the archive?

And if not an archive, how to reasonably handle multi-file packages?

Best,
Graham

Daniel Gibson:
> Is this possible with plain webspace, i.e. when you don't control the server?

If you have your own domain name, you can certainly set this up.

But if your host is fully managed, probably not. A fix is to set
up a redirection server people can share. This is kinda like a
central repository, but you wouldn't have to upload your files
directly. You might just put up a url (and other metadata?) to point
people to the final location.

However, I'd prefer to have simple files. Downloading from git is imo a mistake - those files are probably in development... meaning they are mutable. If the files are mutable, it includes a lot of pain for versioning and caching.

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@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

Am 14.06.2011 17:31, schrieb Adam D. Ruppe:
> Daniel Gibson:
>> Is this possible with plain webspace, i.e. when you don't control the server?
> 
> If you have your own domain name, you can certainly set this up.
> 
> But if your host is fully managed, probably not. A fix is to set
> up a redirection server people can share. This is kinda like a
> central repository, but you wouldn't have to upload your files
> directly. You might just put up a url (and other metadata?) to point
> people to the final location.
> 
> However, I'd prefer to have simple files. Downloading from git is imo a mistake - those files are probably in development... meaning they are mutable. If the files are mutable, it includes a lot of pain for versioning and caching.

There could be stable branches in the git repositories for exactly this
purpose.
Furthermore it's be nice as an additional feature - some people may
always want to use the latest bleeding edge version from git/svn/whatever.