On 2011-06-14 18:34, Vladimir Panteleev wrote:
> On Tue, 14 Jun 2011 17:47:32 +0300, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> Finding weakness in a proposal is easy. The more difficult thing to do
>> is to find ways to improve it or propose alternatives.
>
> I think the only solid alternative is to stop trying to reinvent the
> wheel, and "start up our photocopiers" (copy CPAN/Gems/PECL).

That's what I'm doing (copying Rubygems), see https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D


-- 
/Jacob Carlborg

On 6/17/11 6:18 PM, Jacob Carlborg wrote:
> On 2011-06-14 18:34, Vladimir Panteleev wrote:
>> On Tue, 14 Jun 2011 17:47:32 +0300, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> Finding weakness in a proposal is easy. The more difficult thing to do
>>> is to find ways to improve it or propose alternatives.
>>
>> I think the only solid alternative is to stop trying to reinvent the
>> wheel, and "start up our photocopiers" (copy CPAN/Gems/PECL).
>
> That's what I'm doing (copying Rubygems), see
> https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D

Oh, sorry, I just wanted to fix the typo in the headline, but broke the link as well. Now at: https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D

David

On 6/17/11 6:15 PM, Jacob Carlborg wrote:
> Instead of complaining about others ideas (I'll probably do that as well
> :) ), here's my idea:
> https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D

Sorry, I just wanted to fix the headline, but that changed the URL as well. Now at: https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D

David

> It would be better to download an archive of some sort.

For cases when this is necessary, it'd be easy enough to grab a .zip for the package rather than the .d for the module.

The .zips could take a cue from the Slackware package format too.
They simply puts things in the appropriate folders
to be added to your installation, then zip it right up.

src/package.name/file.d
bin/package.name.dll
lib/package.name.lib
package.name.txt  (this contains metadata if you want it)


You can unzip it locally, in your dmd folder, or whatever and then the files are available for use if your -L and -I paths are good.

Thus, the same basic idea covers binary library distributions too.

This could be in addition to grabbing the .d files alone.

On Fri, Jun 17, 2011 at 1:15 PM, Jacob Carlborg <doob@me.com> wrote:
> On 2011-06-14 15:53, Andrei Alexandrescu wrote:
> Instead of complaining about others ideas (I'll probably do that as well :)
> ), here's my idea:
> https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D

>From website:
> Spec and Config Files
> The dakefile and the orbspec file is written in Ruby. Why?

Why ruby and not D with mixin? I am willing to volunteer some time to this if help is needed.

-Jose

On 2011-06-15 17:37, David Gileadi wrote:
> On 6/14/11 6:53 AM, Andrei Alexandrescu wrote:
>> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
>>
>> Destroy.
>
> I keep thinking that if we build a separate dget, dmd could call it even
> if there weren't a URL embedded in the source. If dget had a list of
> central repositories then it could simply look in them for the
> package/module and compilation would magically work with or without a
> pragma.
>
> In any case I suspect that a more formal versioning system is needed.
> One way of supporting versions would be to make dget aware of source
> control systems like svn, mercurial and git which support tags.
>
> The pragma could support source control URLs, and could also include an
> optional version. dget could be aware of common source control clients,
> and could try calling them if installed, looking for the code tagged
> with the provided version. If no version were specified then head/master
> would be used.

If you just want to clone a repository from, i.e. github or bitbucket you can just do a simple HTTP download, no need for a SCM client.

-- 
/Jacob Carlborg

On 2011-06-15 20:11, Robert Clipsham wrote:
> On 15/06/2011 16:15, Andrei Alexandrescu wrote:
>>> pragma(lib) doesn't (and can't) work as it is, why do you want to add
>>> more useless pragmas?
>>
>> Then we should yank it or change it. That pragma was defined in a
>> completely different context from today's, and right now we have a much
>> larger user base to draw experience and insight from.
>
> Note that rebuild had pragma(link) which got around this problem - it
> was the build tool, it could keep track of all of these without
> modifying object files or other such hackery. So I guess pragma(lib)
> could be fixed in the hypothetical tool.

It's too bad that pragma(lib) doesn't behave like pragma(link), it's quite an easy fix as well. It's also unnecessary to have two tools reading the same files, the build tool for reading pragma(link) and the compiler for reading the whole file to compile it.

-- 
/Jacob Carlborg

On 2011-06-17 18:45, Jose Armando Garcia wrote:
> On Fri, Jun 17, 2011 at 1:15 PM, Jacob Carlborg<doob@me.com>  wrote:
>> On 2011-06-14 15:53, Andrei Alexandrescu wrote:
>> Instead of complaining about others ideas (I'll probably do that as well :)
>> ), here's my idea:
>> https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D
>
>> From website:
>> Spec and Config Files
>> The dakefile and the orbspec file is written in Ruby. Why?
>
> Why ruby and not D with mixin? I am willing to volunteer some time to
> this if help is needed.
>
> -Jose

As I stated just below "The dakefile and the orbspec file is written in Ruby. Why?". D is too verbose for simple files like these. How would it even work? Wrap everything in a main method, compile and then run?

-- 
/Jacob Carlborg

"Jacob Carlborg" <doob@me.com> wrote in message news:itgamg$2ggr$4@digitalmars.com...
> On 2011-06-17 18:45, Jose Armando Garcia wrote:
>> On Fri, Jun 17, 2011 at 1:15 PM, Jacob Carlborg<doob@me.com>  wrote:
>>> On 2011-06-14 15:53, Andrei Alexandrescu wrote:
>>> Instead of complaining about others ideas (I'll probably do that as well
>>> :)
>>> ), here's my idea:
>>> https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D
>>
>>> From website:
>>> Spec and Config Files
>>> The dakefile and the orbspec file is written in Ruby. Why?
>>
>> Why ruby and not D with mixin? I am willing to volunteer some time to this if help is needed.
>>
>> -Jose
>
> As I stated just below "The dakefile and the orbspec file is written in Ruby. Why?". D is too verbose for simple files like these. How would it even work? Wrap everything in a main method, compile and then run?
>

That would be better than forcing Ruby on people.

One option that I see is to create a compiler plugin interface that lets a build tool/package manager hook the compiler's import resolution process.

A very (very) basic implementation: (windows only)
https://github.com/yebblies/dmd/tree/importresolve

For those who don't want to read the source code:
The user (or the build tool, or in sc.ini/dmd.conf) supplies a dll/so on the
command line with:
dmd -ih=mylib.dll
Which exports a single function "_importhandler" that is called when a file
is not found on the include path.  It passes the module name and the
contents of the describing pragma, if any.
eg.
pragma(libver, "collection", "version", "hash")
import xpackage.xmodule;

calls
filename = importhandler("xpackage.xmodule", "collection", "version",
"hash")

and lets the library download, update etc, and return the full filename of the required library.