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

Destroy.


Andrei

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

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

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

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

It ultimately seems slap-dash and underspecified. Vladimir brings up a lot of good criticisms. I don't this is something that I'd support in its current state.

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

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.

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

Cheers,
- Daniel

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

This is pretty similar to what my build.d does, except I assume
the base url instead of letting it be specified. (I considered having
a metadata file, but since I control the server anyway, I don't need
it for me!)

What I like is that it's a very simple idea that has no central point of failure.

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.

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.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 6/14/11 9:09 AM, Vladimir Panteleev wrote:
> 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.

The way I see it, transitivity should take care of this. Consider:

// File http://dsource.org/libs/mysql.d
pragma(liburl, mysql, "http://some.site.org/d/mysql.d")
import mysql;

// User file
pragma(liburl, dsource, "http://dsource.org/libs/");
import dsource.mysql;

With transitivity you can arrange central repos via an additional level of indirection.

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

URL includes https and ftp.

> 3) It only solves the problem for D modules, but not any other possible
> dependencies.

Correct. So we should extend this towards handling other scenarios too.

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

Finding weakness in a proposal is easy. The more difficult thing to do is to find ways to improve it or propose alternatives.


Andrei

On 6/14/11 9:28 AM, Bernard Helyer wrote:
> On Tue, 14 Jun 2011 08:53:16 -0500, Andrei Alexandrescu wrote:
>
>> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
>>
>> Destroy.
>
> It ultimately seems slap-dash and underspecified. Vladimir brings up a
> lot of good criticisms. I don't this is something that I'd support in its
> current state.

I think many of Vladimir's points are themselves hasty. Please improve.

Thanks,

Andrei

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");

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


Andrei