DIP11

[Nick Sabalausky]

"Jonas Drewsen" <jdrewsen at nospam.com> wrote in message 
news:j20139$2sev$1 at digitalmars.com...
> On 11/08/11 09.07, Jacob Carlborg wrote:
>> On 2011-08-10 21:55, jdrewsen wrote:
>>> What is the status of DIP11
>>>
>>> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
>>>
>>> Has anyone started implementing it? Has it been rejected?
>>>
>>> /Jonas
>>
>> Not sure, personally I don't like it. Instead I'm working on a more
>> traditional package manager called Orbit:
>> https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
>
> Yes I've noticed that. Seems very promising.
>
> What I do like about DIP11 is how seamless it would work. You just have to 
> compile and stuff works.
>

I really see it as solving the wrong problem the wrong way.

DIP11 tries to solve two main things:

1. Automatic downloading of external dependencies.

2. Eliminate the need for a separate invokation of DMD to find all needed D 
files (ie, efficiency).

I strongly believe that #1 is best handled at the "package/library" level 
(and by that I'm referring to the "package manager" concept of "packages", 
not D's module system). DIP11 handles this at the individual source-file 
level, which I believe is wrong and causes plenty of problems. Plus, DIP11 
is very, very limited compared to a tradtional-style package manager (and 
pretty much has to be since it works at the individual source-file level) 
and thus encourages very bad things like hardcoding exactly one possible 
location from which to retrieve a given file.

Regarding #2, if that is deemed a real problem, then that can be solved by 
incorporating RDMD's "--build-only" functionality into the compiler (as an 
optional flag). This has two benefits over DIP11: A, It just works, nobody 
ever has to deal with DIP11's weird "DMD wants X to be retrieved", umm, 
"callback" mechanism. B, It's not tied to DIP11's broken package management 
design.

Not only that, but DIP11, strangely enough, *fails* to solve issue #2 at 
all: It may download the needed D files, but it won't compile them. A 
separate tool *still* has to pass all the D files to DMD. And to do that it 
needs to know what D files are needed. And to do that, it needs to either 
ask DMD or be told by DMD, and *then* send all the D files to DMD as a 
separate invokation.

The motivation for DIP11 was clearly to get a D package-retreiving system up 
and running with minimal effort. And that would be great if it were a good 
proposal. But DIP11 just smacks of corner-cutting.