www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Release DUB 0.9.25, new logo and updated website design

reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
This version marks the final milestone before the 1.0.0 release, which 
is scheduled for mid-June. The API has been cleaned up and will be kept 
backwards compatible throughout 1.x.x (0.9.25->1.0.0 may still have some 
breaking changes). Beginning with version 1.0.0, DUB will also become 
part of the DMD compiler distribution, so that no additional setup will 
be required to build DUB projects.

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!).

Some major changes to DUB itself are:

  - Builds on frontend versions up to 2.071.0
  - Implements proper optional dependency semantics, where using an
    optional dependency can now be controlled using dub.selections.json
  - "dub init" is now interactive by default (use -n to disable)
  - Contains some critical changes regarding path based dependencies
  - New "convert" and "search" commands
  - It now supports "git submodule" style packages that put their D
    sources at the root of the repository and expect to be checked out
    into a folder with the name of the package/repository. This builds
    on a new folder structure for downloaded packages and may require a
    re-download of affected packages to take effect. If you run into any
    issues, try removing all cached packages with "dub remove *".

Full change log:
https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

Download:
http://code.dlang.org/download
May 22 2016
next sibling parent Bauss <jj_1337 live.dk> writes:
On Sunday, 22 May 2016 at 19:36:39 UTC, Sönke Ludwig wrote:

 This version marks the final milestone before the 1.0.0 
 release, which is scheduled for mid-June. The API has been 
 cleaned up and will be kept backwards compatible throughout 
 1.x.x (0.9.25->1.0.0 may still have some breaking changes). 
 Beginning with version 1.0.0, DUB will also become part of the 
 DMD compiler distribution, so that no additional setup will be 
 required to build DUB projects.

 [...]


I love the new look!

Congratulations on the latest version!
May 22 2016
prev sibling next sibling parent Dmitry <dmitry indiedev.ru> writes:
On Sunday, 22 May 2016 at 19:36:39 UTC, Sönke Ludwig wrote:

 registry, and the site style has been adjusted to fit the 
 general dlang.org design (thanks to Sebastian Wilzbach!).


Hi. Is possible change font to something more readable?
For example, like font on http://dlang.org
May 22 2016
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 22 May 2016 at 19:36:39 UTC, Sönke Ludwig wrote:

 This version marks the final milestone before the 1.0.0 
 release, which is scheduled for mid-June. The API has been 
 cleaned up and will be kept backwards compatible throughout 
 1.x.x (0.9.25->1.0.0 may still have some breaking changes). 
 Beginning with version 1.0.0, DUB will also become part of the 
 DMD compiler distribution, so that no additional setup will be 
 required to build DUB projects.


Nice work, looking forward to seeing dub be part of the dmd 
package, hope the same can be done for ldc.

I'll see if I can get it running on Android/ARM, don't want to 
leave out those who want to build D libraries on their Android 
tablet. ;)
May 22 2016
parent Guillaume Piolat <first.last gmail.com> writes:
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.
May 23 2016
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-05-22 21:36, Sönke Ludwig wrote:

 This version marks the final milestone before the 1.0.0 release, which
 is scheduled for mid-June. The API has been cleaned up and will be kept
 backwards compatible throughout 1.x.x (0.9.25->1.0.0 may still have some
 breaking changes). Beginning with version 1.0.0, DUB will also become
 part of the DMD compiler distribution, so that no additional setup will
 be required to build DUB projects.

 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!).

 Some major changes to DUB itself are:

   - Builds on frontend versions up to 2.071.0
   - Implements proper optional dependency semantics, where using an
     optional dependency can now be controlled using dub.selections.json
   - "dub init" is now interactive by default (use -n to disable)
   - Contains some critical changes regarding path based dependencies
   - New "convert" and "search" commands
   - It now supports "git submodule" style packages that put their D
     sources at the root of the repository and expect to be checked out
     into a folder with the name of the package/repository. This builds
     on a new folder structure for downloaded packages and may require a
     re-download of affected packages to take effect. If you run into any
     issues, try removing all cached packages with "dub remove *".

 Full change log:
 https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

 Download:
 http://code.dlang.org/download


The styling of [1] is a bit inconsistent. The styling for inline code, 
i.e. <code>, seem to have bigger font than both the regular text and the 
larger code blocks, <pre class="code">.

It looks like the changelog entry "Path based dependencies are now also 
stored in dub.selections.json" links to the wrong issue.

[1] http://code.dlang.org/package-format?lang=json

-- 
/Jacob Carlborg
May 22 2016
next sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 23.05.2016 um 08:33 schrieb Jacob Carlborg:

 The styling of [1] is a bit inconsistent. The styling for inline code,
 i.e. <code>, seem to have bigger font than both the regular text and the
 larger code blocks, <pre class="code">.


On which browser/OS? I've now removed the border/background color, but 
the font size looks fine for me on Linux.


 It looks like the changelog entry "Path based dependencies are now also
 stored in dub.selections.json" links to the wrong issue.





 [1] http://code.dlang.org/package-format?lang=json
May 22 2016
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-05-23 08:52, Sönke Ludwig wrote:


 On which browser/OS?


On OS X using Safari, Chrome or Firefox.


 I've now removed the border/background color,


I think the background and border looked fine.


 but the font size looks fine for me on Linux.


Using Firefox:

The inline code has font size 15px. I think "Andale Mono" is the font 
that is actually used.

For the code blocks, the font size is 13px and the font is "Courier New".

The rest of the text is using "Roboto Slab" and 15px.

-- 
/Jacob Carlborg
May 23 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 23.05.2016 um 09:01 schrieb Jacob Carlborg:

 On 2016-05-23 08:52, Sönke Ludwig wrote:


 On which browser/OS?


 On OS X using Safari, Chrome or Firefox.


 I've now removed the border/background color,


 I think the background and border looked fine.


It looked out of place on non-Mac systems. On OS X on the other hand, 
the monospace font is rendered hardly different from the serif one. I've 
added the border back, but lighter and with vertical padding, which 
looks okay on both systems.


 but the font size looks fine for me on Linux.


 Using Firefox:

 The inline code has font size 15px. I think "Andale Mono" is the font
 that is actually used.

 For the code blocks, the font size is 13px and the font is "Courier New".

 The rest of the text is using "Roboto Slab" and 15px.


Okay, removed the old "Courier New" reference and both are rendered the 
same now.
May 23 2016
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Monday, 23 May 2016 at 08:04:51 UTC, Sönke Ludwig wrote:

 Am 23.05.2016 um 09:01 schrieb Jacob Carlborg:

 On 2016-05-23 08:52, Sönke Ludwig wrote:


 On which browser/OS?


 On OS X using Safari, Chrome or Firefox.


 I've now removed the border/background color,


 I think the background and border looked fine.


 It looked out of place on non-Mac systems. On OS X on the other 
 hand, the monospace font is rendered hardly different from the 
 serif one. I've added the border back, but lighter and with 
 vertical padding, which looks okay on both systems.


 but the font size looks fine for me on Linux.


 Using Firefox:

 The inline code has font size 15px. I think "Andale Mono" is 
 the font
 that is actually used.

 For the code blocks, the font size is 13px and the font is 
 "Courier New".

 The rest of the text is using "Roboto Slab" and 15px.


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


The flavicon is still the old one and appears in search engine 
results.
May 23 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 23.05.2016 um 11:22 schrieb Chris:

 The flavicon is still the old one and appears in search engine results.


For some reason, favicons are cached aggressively. It has been updated, 
but it's hard to get the browsers pick it up.
May 23 2016
parent reply Chris <wendlec tcd.ie> writes:
On Monday, 23 May 2016 at 09:23:45 UTC, Sönke Ludwig wrote:

 Am 23.05.2016 um 11:22 schrieb Chris:

 The flavicon is still the old one and appears in search engine 
 results.


 For some reason, favicons are cached aggressively. It has been 
 updated, but it's hard to get the browsers pick it up.


I thought it might be a caching issue. I don't know about the 
search engines though. Can you inform them of the update? I 
opened the page in a different browser and it shows the new 
favicon, but in the search results it's still the old icon.
May 23 2016
next sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 23.05.2016 um 11:30 schrieb Chris:

 On Monday, 23 May 2016 at 09:23:45 UTC, Sönke Ludwig wrote:

 Am 23.05.2016 um 11:22 schrieb Chris:

 The flavicon is still the old one and appears in search engine results.


 For some reason, favicons are cached aggressively. It has been
 updated, but it's hard to get the browsers pick it up.


 I thought it might be a caching issue. I don't know about the search
 engines though. Can you inform them of the update? I opened the page in
 a different browser and it shows the new favicon, but in the search
 results it's still the old icon.


I'd hope that that would be part of the usual refresh cycle. At least 
I've never seen an option related to this.
May 23 2016
prev sibling parent Chris <wendlec tcd.ie> writes:
On Monday, 23 May 2016 at 09:30:25 UTC, Chris wrote:

 On Monday, 23 May 2016 at 09:23:45 UTC, Sönke Ludwig wrote:

 Am 23.05.2016 um 11:22 schrieb Chris:

 The flavicon is still the old one and appears in search 
 engine results.


 For some reason, favicons are cached aggressively. It has been 
 updated, but it's hard to get the browsers pick it up.


 I thought it might be a caching issue. I don't know about the 
 search engines though. Can you inform them of the update? I 
 opened the page in a different browser and it shows the new 
 favicon, but in the search results it's still the old icon.


My search engine now shows the new favicon.
May 24 2016
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
May 23 2016
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-05-23 08:52, Sönke Ludwig wrote:





Not pushed?

-- 
/Jacob Carlborg
May 23 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 23.05.2016 um 09:03 schrieb Jacob Carlborg:

 On 2016-05-23 08:52, Sönke Ludwig wrote:





 Not pushed?


Pushed now, didn't notice that the push failed due to out-of-date local 
branch.
May 23 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-05-23 09:06, Sönke Ludwig wrote:


 Pushed now, didn't notice that the push failed due to out-of-date local
 branch.


It looks correct now, thanks.

-- 
/Jacob Carlborg
May 23 2016
prev sibling parent reply qznc <qznc web.de> writes:
On Monday, 23 May 2016 at 06:33:15 UTC, Jacob Carlborg wrote:

 The styling of [1] is a bit inconsistent. The styling for 
 inline code, i.e. <code>, seem to have bigger font than both 
 the regular text and the larger code blocks, <pre class="code">.

 [1] http://code.dlang.org/package-format?lang=json


Mixing fonts is hard. Both fonts must have the same size, but 
also the same x-height [0], which is the height of lowercase 
letters like x. This can be seen very clearly with inline code 
like "contain a <code>dub.json</code>" at the page you linked to. 
Zoom in (Ctrl+) and you see the height difference between "a" and 
"u".

On websites where fonts are picked from whatever is available on 
the system, this is nearly impossible to get right. You either 
live with it or embed your own fonts via CSS, which bloats the 
page.

[0] https://en.wikipedia.org/wiki/X-height
May 23 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-05-23 12:38, qznc wrote:


 Mixing fonts is hard. Both fonts must have the same size, but also the
 same x-height [0], which is the height of lowercase letters like x. This
 can be seen very clearly with inline code like "contain a
 <code>dub.json</code>" at the page you linked to. Zoom in (Ctrl+) and
 you see the height difference between "a" and "u".

 On websites where fonts are picked from whatever is available on the
 system, this is nearly impossible to get right. You either live with it
 or embed your own fonts via CSS, which bloats the page.

 [0] https://en.wikipedia.org/wiki/X-height


A start is to use the same font size ;)

-- 
/Jacob Carlborg
May 23 2016
prev sibling next sibling parent reply Russel Winder via Digitalmars-d-announce writes:
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.=C2=A0

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
May 23 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
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.
May 23 2016
next sibling parent Russel Winder via Digitalmars-d-announce writes:
On Mon, 2016-05-23 at 15:19 +0200, S=C3=B6nke Ludwig via Digitalmars-d-
announce wrote:

=20


[=E2=80=A6]

 Online docs are still on the TODO list, but you can do
=20
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dub fetch dub
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dub run dub -b ddox
=20
 And it will start up a local HTTP server on http://127.0.0.1:8080/
 with=C2=A0
 the API documentation.


OK will go with that=E2=80=A6 did nots of downloading and other stuff and t=
hen:

    =E2=80=A6
    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.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
May 23 2016
prev sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Mon, 2016-05-23 at 15:19 +0200, S=C3=B6nke Ludwig via Digitalmars-d-
announce wrote:

 Am 23.05.2016 um 15:01 schrieb Russel Winder via Digitalmars-d-
 announce:

 Hi,
=20
 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.
=20


=20
 Online docs are still on the TODO list, but you can do
=20
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dub fetch dub
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dub run dub -b ddox
=20
 And it will start up a local HTTP server on http://127.0.0.1:8080/
 with=C2=A0
 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. =C2=A0It 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?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
May 23 2016
next sibling parent reply Dicebot <public dicebot.lv> writes:
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
May 23 2016
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
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.
May 23 2016
prev sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
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...
May 23 2016
next sibling parent Russel Winder via Digitalmars-d-announce writes:
On Mon, 2016-05-23 at 17:40 +0200, S=C3=B6nke Ludwig via Digitalmars-d-
announce wrote:


=20
 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
=20
 GET /packages/[package].json
 Returns a JSON object with general information about a package,=C2=A0
 including all available versions
=20
 GET /packages/[package]/[version].json
 Returns a JSON object with the package recipe of a particular
 version=C2=A0
 (dub.json format), augmented with some additional fields
=20
 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.


=20
 There is also a separate search API (and some other less interesting
 APIs):
=20
 GET /api/packages/search?q=3D...
=20
=20
 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. :-)

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
May 23 2016
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-05-23 17:40, Sönke Ludwig wrote:


 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


So dependencies are fetched when they are discovered based on a package? 
Wouldn't it be more efficient to have an API call that given a list of 
packages, returns the full set of dependencies in one call. Then it 
would be possible to fetch the dependencies in parallel.

-- 
/Jacob Carlborg
May 23 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 24.05.2016 um 08:24 schrieb Jacob Carlborg:

 On 2016-05-23 17:40, Sönke Ludwig wrote:


 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


 So dependencies are fetched when they are discovered based on a package?
 Wouldn't it be more efficient to have an API call that given a list of
 packages, returns the full set of dependencies in one call. Then it
 would be possible to fetch the dependencies in parallel.


Since fetching dependencies usually saturates the network connection, 
that wouldn't save much time (or do you just mean fetching the package 
recipes in parallel?). But because it also requires full dependency 
resolution, it would have a considerable impact on server load. And of 
course that would make it impossible to use a simple file server as a 
package registry.
May 23 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-05-24 08:42, Sönke Ludwig wrote:


 Since fetching dependencies usually saturates the network connection,
 that wouldn't save much time (or do you just mean fetching the package
 recipes in parallel?).


No, I mean fetching the full package in parallel.


 But because it also requires full dependency
 resolution, it would have a considerable impact on server load.


Does it really take that much resources?


 And of course that would make it impossible to use a simple file server as a
 package registry.


How important is that? The client could first try the API call to give 
the full set of dependencies, if that fail, fallback to the current 
approach.

-- 
/Jacob Carlborg
May 24 2016
prev sibling next sibling parent reply Russel Winder via Digitalmars-d-announce writes:
Is there an ordering to the entries on the page?

Apologies if the ordering algorithm is obvious, I am having a relative
brain-dead day today.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
May 23 2016
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 23.05.2016 um 15:02 schrieb Russel Winder via Digitalmars-d-announce:

 Is there an ordering to the entries on the page?

 Apologies if the ordering algorithm is obvious, I am having a relative
 brain-dead day today.


You can click the column headers at the top. The default ordering is by 
latest update (latest tagged version).
May 23 2016
prev sibling next sibling parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
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.
May 23 2016
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
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.
May 23 2016
prev sibling parent reply Adrian Matoga <dlang.spam matoga.info> writes:
On Sunday, 22 May 2016 at 19:36:39 UTC, Sönke Ludwig wrote:

 (...)


The new site is cool, except a few annoyances:

1. The font is much thinner than on dlang.org main site 
(font-weight set to 300 for no good reason), and thus much harder 

even harder. Come on, perhaps most of us already have some sort 
of vision defects, please do not make it worse.

2. Project READMEs now render with different font which looks 
weird. (OTOH, the README alone looks nicer and easier on eyes, 
because plain Helvetica or Arial are just better suited for 
on-screen reading than clumsy serif fonts like roboto slab).

3. Clicking the top-left dub logo directs to 
"http://code.dlang.org/packages/" which is 404.

4. List of available versions for a package is broken: the most 
recent version is repeated multiple times and is not a hyperlink.

Also, some parts of READMEs are not rendered the way they are on 
github, like: nested lists, [ ]/[x] progress ticks, syntax 
highlighting in code snippets.
May 24 2016
parent Adrian Matoga <dlang.spam matoga.info> writes:
On Tuesday, 24 May 2016 at 22:59:24 UTC, Adrian Matoga wrote:

 (...)
 1. The font is much thinner than on dlang.org main site


PR: https://github.com/dlang/dub-registry/pull/156


 3. Clicking the top-left dub logo directs to 
 "http://code.dlang.org/packages/" which is 404.


PR: https://github.com/dlang/dub-registry/pull/157
May 24 2016