"Jonas Drewsen" <jdrew...@nospam.com> wrote in message news:j20139$2sev$1...@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.