DIP11

Jacob Carlborg doob at me.com
Thu Aug 11 09:43:11 PDT 2011


On 2011-08-11 17:41, Nick Sabalausky wrote:
> "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.

I completely agree with this.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list