On Mon, 2016-05-23 at 15:19 +0200, Sönke Ludwig via Digitalmars-d- announce wrote:
> 
[…]
> Online docs are still on the TODO list, but you can do
> 
>      dub fetch dub
>      dub run dub -b ddox
> 
> And it will start up a local HTTP server on http://127.0.0.1:8080/
> with
> the API documentation.

OK will go with that… did nots of downloading and other stuff and then:

    …
    Linking...
    /usr/bin/ld: cannot find -levent
    /usr/bin/ld: cannot find -levent_pthreads
    collect2: error: ld returned 1 exit status
    --- errorlevel 1
    dmd failed with exit code 1.

It seems that there is a dependency that is not being checked at the start of processing.

Clearly installing libevent-dev (on Debian Sid) cures the problem, but I would have expected a build system to check requirements such as this very early on.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, 2016-05-23 at 15:19 +0200, Sönke Ludwig via Digitalmars-d- announce wrote:
> Am 23.05.2016 um 15:01 schrieb Russel Winder via Digitalmars-d- announce:
> > Hi,
> > 
> > Is the Dub API published anywhere. I propose to write a dmd/ldc/gdc
> > subtool so that dependency management based on the Dub repository
> > is
> > provided for SCons D builds.
> > 
> 
> Online docs are still on the TODO list, but you can do
> 
>      dub fetch dub
>      dub run dub -b ddox
> 
> And it will start up a local HTTP server on http://127.0.0.1:8080/
> with
> the API documentation.

I think I have not expressed my needs as I intended. The above is about the code that runs, I am more interested in the way of interacting with a running server. I appreciate this latter is (sort of) contained in the former, but I think they are two different needs and so require different documentation.  It sounds as though all forms of documentation are on the "not done yet" which is understandable.

My need is two write a Python program that queries the running Dub repository. So I am guessing this is an HTTP-based protocol.

I guess I will have to read the Dub code and deduce/infer/guess the necessary protocol. Not a problem, but it would have been easier for me not to have to do this but to have the API. Is there a repository with the beginnings of something that I might contribute to?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sunday, 22 May 2016 at 21:19:53 UTC, Joakim wrote:
>
> Nice work, looking forward to seeing dub be part of the dmd package, hope the same can be done for ldc.
>

This can't happen soon enough!
When doing client work, it will be easier to push D as a solution if the explanations for builds have one less install step. Not everyone is technical and this would avoid discussing things like PATH.

On Monday, 23 May 2016 at 15:13:56 UTC, Russel Winder wrote:
> My need is two write a Python program that queries the running Dub repository. So I am guessing this is an HTTP-based protocol.
>
> I guess I will have to read the Dub code and deduce/infer/guess the necessary protocol. Not a problem, but it would have been easier for me not to have to do this but to have the API. Is there a repository with the beginnings of something that I might contribute to?

Here is the declaration of REST API : https://github.com/dlang/dub-registry/blob/master/source/dubregistry/api.d#L21-L39

For example: http://code.dlang.org/api/packages/dub/info

Am 23.05.2016 um 17:13 schrieb Russel Winder via Digitalmars-d-announce:
> On Mon, 2016-05-23 at 15:19 +0200, Sönke Ludwig via Digitalmars-d-
> announce wrote:
>> Am 23.05.2016 um 15:01 schrieb Russel Winder via Digitalmars-d-
>> announce:
>>> Hi,
>>>
>>> Is the Dub API published anywhere. I propose to write a dmd/ldc/gdc
>>> subtool so that dependency management based on the Dub repository
>>> is
>>> provided for SCons D builds.
>>>
>>
>> Online docs are still on the TODO list, but you can do
>>
>>       dub fetch dub
>>       dub run dub -b ddox
>>
>> And it will start up a local HTTP server on http://127.0.0.1:8080/
>> with
>> the API documentation.
>
> I think I have not expressed my needs as I intended. The above is about
> the code that runs, I am more interested in the way of interacting with
> a running server. I appreciate this latter is (sort of) contained in
> the former, but I think they are two different needs and so require
> different documentation.  It sounds as though all forms of
> documentation are on the "not done yet" which is understandable.
>
> My need is two write a Python program that queries the running Dub
> repository. So I am guessing this is an HTTP-based protocol.
>
> I guess I will have to read the Dub code and deduce/infer/guess the
> necessary protocol. Not a problem, but it would have been easier for me
> not to have to do this but to have the API. Is there a repository with
> the beginnings of something that I might contribute to?
>

Oh, okay, misunderstood that. The basic protocol is very simple:

GET /packages/index.json
Yields a JSON array with all package names

GET /packages/[package].json
Returns a JSON object with general information about a package, including all available versions

GET /packages/[package]/[version].json
Returns a JSON object with the package recipe of a particular version (dub.json format), augmented with some additional fields

GET /packages/[package]/[version].zip
Yields a zipped up version of the package


There is also a separate search API (and some other less interesting APIs):

GET /api/packages/search?q=...


We should really get that written down on a web page...

Am 23.05.2016 um 17:31 schrieb Dicebot:
> On Monday, 23 May 2016 at 15:13:56 UTC, Russel Winder wrote:
>> My need is two write a Python program that queries the running Dub
>> repository. So I am guessing this is an HTTP-based protocol.
>>
>> I guess I will have to read the Dub code and deduce/infer/guess the
>> necessary protocol. Not a problem, but it would have been easier for
>> me not to have to do this but to have the API. Is there a repository
>> with the beginnings of something that I might contribute to?
>
> Here is the declaration of REST API :
> https://github.com/dlang/dub-registry/blob/master/source/dubregistry/api.d#L21-L39
>
>
> For example: http://code.dlang.org/api/packages/dub/info
>

Just to explain the context. The original API was made in a way that any simple webserver with file serving support could be used as a valid package registry. The REST API is newer and has a broader scope.

For any tool that wants to be as compatible as possible with registries other than code.dlang.org, using the original API would be the better choice. If that's not a concern, using the /api/* endpoints is just as good and offers some more possibilities.

On Sunday, 22 May 2016 at 19:36:39 UTC, Sönke Ludwig wrote:
> In preparation to that, it also received a thorough optical overhaul. The newly designed logo (which has appeared in some other spots already) has been integrated on the package registry, and the site style has been adjusted to fit the general dlang.org design (thanks to Sebastian Wilzbach!).

Shouldn't the dub command-line interface documentation be part of the "Documentation" menu pop-down? Right now we have to go to:

Header -> Documentation -> Getting Started -> Scroll down past lots of text -> Command line interface

Also, a minor improvement might be to:

1) have examples in the dub command line interface. E.g.  after the general usage fixed-width block, have something simple like a sequence of dub build, dub run, etc, for those that are just skimming the documentation and just want to get the general ideia. In the build section have a simple example followed by a more complex one which shows the more advanced use cases, and so on.

2) have more context of what some of the options are. People might read, say, the documentation of --build and see the option of ddox but have no idea what that is/means.

On Mon, 2016-05-23 at 17:40 +0200, Sönke Ludwig via Digitalmars-d- announce wrote:

> 
> Oh, okay, misunderstood that. The basic protocol is very simple:

My fault, I rushed my original email and didn't set out the problem properly.

> GET /packages/index.json
> Yields a JSON array with all package names
> 
> GET /packages/[package].json
> Returns a JSON object with general information about a package,
> including all available versions
> 
> GET /packages/[package]/[version].json
> Returns a JSON object with the package recipe of a particular
> version
> (dub.json format), augmented with some additional fields
> 
> GET /packages/[package]/[version].zip
> Yields a zipped up version of the package

Sponditious. I will see if I can query the server to create a suitable dictionary each time so as to avoid caching results, or whether caching and updating is necessary.

> 
> There is also a separate search API (and some other less interesting
> APIs):
> 
> GET /api/packages/search?q=...
> 
> 
> We should really get that written down on a web page...

The above is close to all that is needed for those of us want an API for working with a running server.

I might even use this is Python Workshops for testing HTTP APIs. :-)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Am 23.05.2016 um 17:55 schrieb Luís Marques:
> On Sunday, 22 May 2016 at 19:36:39 UTC, Sönke Ludwig wrote:
>> In preparation to that, it also received a thorough optical overhaul.
>> The newly designed logo (which has appeared in some other spots
>> already) has been integrated on the package registry, and the site
>> style has been adjusted to fit the general dlang.org design (thanks to
>> Sebastian Wilzbach!).
>
> Shouldn't the dub command-line interface documentation be part of the
> "Documentation" menu pop-down? Right now we have to go to:
>
> Header -> Documentation -> Getting Started -> Scroll down past lots of
> text -> Command line interface

Yes, actually I had committed that change already, and just didn't rebuild the site yet :)

>
> Also, a minor improvement might be to:
>
> 1) have examples in the dub command line interface. E.g.  after the
> general usage fixed-width block, have something simple like a sequence
> of dub build, dub run, etc, for those that are just skimming the
> documentation and just want to get the general ideia. In the build
> section have a simple example followed by a more complex one which shows
> the more advanced use cases, and so on.
>
> 2) have more context of what some of the options are. People might read,
> say, the documentation of --build and see the option of ddox but have no
> idea what that is/means.

The information is currently procedurally generated from  the CLI --help (queried from the dub library), so most improvements should probably happen in that area. But adding some extra introduction/examples to the global section would of course fit well in the web page template, too.

On 2016-05-23 10:04, Sönke Ludwig wrote:

> Okay, removed the old "Courier New" reference and both are rendered the
> same now.

Looks better now.

-- 
/Jacob Carlborg