Currently, getting D code from github is a multistep process, that isn't always obvious. I propose the creation of a dget program, which will:

    dget https://github.com/D-Programming-Deimos/libevent

download the libevent code and install it in a subdirectory named libevent. Of course, the url could also be:

    dget github.com/D-Programming-Deimos/libevent

since https is assumed, or:

    dget D-Programming-Deimos/libevent

since github is assumed. And since Deimos is a known library,

    dget libevent

can also be hardwired into dget.

Anyone want to implement such? It ought to be fairly straightforward, and will be a nice timesaver for a lot of people.

On 24-05-2012 01:14, Walter Bright wrote:
> Currently, getting D code from github is a multistep process, that isn't
> always obvious. I propose the creation of a dget program, which will:
>
> dget https://github.com/D-Programming-Deimos/libevent
>
> download the libevent code and install it in a subdirectory named
> libevent. Of course, the url could also be:
>
> dget github.com/D-Programming-Deimos/libevent
>
> since https is assumed, or:
>
> dget D-Programming-Deimos/libevent
>
> since github is assumed. And since Deimos is a known library,
>
> dget libevent
>
> can also be hardwired into dget.
>
> Anyone want to implement such? It ought to be fairly straightforward,
> and will be a nice timesaver for a lot of people.

Maybe this should be part of whatever package manager the community ends up using. I think several people have been / are working on such programs.

BTW, Git submodules are ideal for this sort of thing: http://git-scm.com/book/en/Git-Tools-Submodules

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Wednesday, 23 May 2012 at 23:14:19 UTC, Walter Bright wrote:
> Currently, getting D code from github is a multistep process, that isn't always obvious. I propose the creation of a dget program, which will:
>
>     dget https://github.com/D-Programming-Deimos/libevent
>
> download the libevent code and install it in a subdirectory named libevent.

What are you referring to as installation? Just retrieving the source into a »libevent« subdirectory is hardly a multi-step process:

git clone https://github.com/D-Programming-Deimos/libevent

David

On 5/23/2012 9:39 PM, David Nadlinger wrote:
> On Wednesday, 23 May 2012 at 23:14:19 UTC, Walter Bright wrote:
>> Currently, getting D code from github is a multistep process, that isn't
>> always obvious. I propose the creation of a dget program, which will:
>>
>> dget https://github.com/D-Programming-Deimos/libevent
>>
>> download the libevent code and install it in a subdirectory named libevent.
>
> What are you referring to as installation? Just retrieving the source into a
> »libevent« subdirectory is hardly a multi-step process:
>
> git clone https://github.com/D-Programming-Deimos/libevent

Pretty much that. However, this requires that the user install git first. dget is all about reducing friction. dget can also be extended to get things from other repositories without changing the user interface, and it can have a builtin mapping of library=>url for popular packages.

For an analogy, if I wanted to check the documentation for std.algorithm, I could of course fire up the browser and type:

    http://dlang.org/phobos/std_algorithm.html

in the address bar. Or, I could write:

    dman std.algorithm

and I'm there. And I can type:

    dman link

and the web page for http://www.digitalmars.com/ctg/optlink.html opens up. It's all about reducing the friction. I am often surprised at how simple things like this turn out to be tipping points for users (and myself).

On 5/24/12 6:14 AM, Walter Bright wrote:
> Currently, getting D code from github is a multistep process, that isn't
> always obvious. I propose the creation of a dget program, which will:
>
> dget https://github.com/D-Programming-Deimos/libevent
>
> download the libevent code and install it in a subdirectory named
> libevent. Of course, the url could also be:
>
> dget github.com/D-Programming-Deimos/libevent
>
> since https is assumed, or:
>
> dget D-Programming-Deimos/libevent
>
> since github is assumed. And since Deimos is a known library,
>
> dget libevent
>
> can also be hardwired into dget.
>
> Anyone want to implement such? It ought to be fairly straightforward,
> and will be a nice timesaver for a lot of people.

I think it's better to focus on a package manager that will make this 'dget' program obsolete.

On Thursday, May 24, 2012 12:45:57 Ary Manzana wrote:
> I think it's better to focus on a package manager that will make this 'dget' program obsolete.

Though dget would be a pretty good name for a D package manager.

- Jonathan M Davis

On 5/23/2012 10:51 PM, Jonathan M Davis wrote:
> On Thursday, May 24, 2012 12:45:57 Ary Manzana wrote:
>> I think it's better to focus on a package manager that will make this
>> 'dget' program obsolete.
>
> Though dget would be a pretty good name for a D package manager.

And dget is a one or two day project, and doesn't require much of any design.

On 24-05-2012 07:51, Jonathan M Davis wrote:
> On Thursday, May 24, 2012 12:45:57 Ary Manzana wrote:
>> I think it's better to focus on a package manager that will make this
>> 'dget' program obsolete.
>
> Though dget would be a pretty good name for a D package manager.
>
> - Jonathan M Davis

+1.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 2012-05-24 07:42, Walter Bright wrote:

> Pretty much that. However, this requires that the user install git
> first. dget is all about reducing friction. dget can also be extended to
> get things from other repositories without changing the user interface,
> and it can have a builtin mapping of library=>url for popular packages.

This is the job for a package manager, not some specialized wget.

-- 
/Jacob Carlborg

On 2012-05-24 07:57, Walter Bright wrote:

> And dget is a one or two day project, and doesn't require much of any
> design.

Then suddenly you want to be able to easily download dependencies and install all code in a central location on disk, i.e. a package manager. But since the original tool "doesn't require much of any design" everything turns out to be a big mess.

-- 
/Jacob Carlborg