Dub, Cargo, Go, Gradle, Maven

[Dmitry Olshansky]

On Friday, 16 February 2018 at 22:48:55 UTC, H. S. Teoh wrote:
> On Fri, Feb 16, 2018 at 07:31:37PM +0000, Dmitry Olshansky via 
> Digitalmars-d wrote:
>> On Friday, 16 February 2018 at 18:16:12 UTC, H. S. Teoh wrote:
> [...]
>> > If a dependent node requires network access, it forces 
>> > network access every time the DAG is updated.  This is slow, 
>> > and also unreliable: the shape of the DAG could, in theory, 
>> > change arbitrarily at any time outside the control of the 
>> > user.
>> 
>> Oh, come on. Immutable artifacts make this matter trivial - 
>> the first step is resolution, where you figure out what things 
>> you already have by looking at metadata only, followed by 
>> download the world (or part you do not have).  Since specific 
>> versions never change, nothing to worry about. Java folks had 
>> this for ages with Maven and its ilk.
>
> This assumes that the upstream server (1) consistently serves 
> the same data for the same version -- which in principle will 
> be the case, but unforeseen problems could break this 
> assumption;

Trivially enforced on public hubs such maven central.

  (2) stores all versions forever, which is unlikely
> to be always true.


Is in fact true. After all github stores the whole git repo why 
would storing all distinct versions be too much.


> In any case, dependence on network access for every invocation 
> of a build is unacceptable to me.

Well, it is not in the scheme outlined. Only the clean build is.

> [...]
>> Also most if not all build systems will inevitably integrate 
>> all of
>> the below in some way:
>> - compiler (internal as library or external as a build server)
>> - source code dependency resolution
>> - package dependency resolution
>> - package download or build
>> - execution of arbitrary tasks in form of plugins or external 
>> tools
>> 
>> Me personally in love with plugins and general purpose 
>> language available to define tasks. Scala’s SBT may have many 
>> faults but plugins and extensibility make it awesome.
>
> Personally, I find that the most useful build systems are those 
> that make no assumptions about how your products are built.

No thanks, I’d prefer convention then unique snowflake build 
scripts if there us a choice. Sometimes you have to do go beyound 
ghe basics but not too often.

> SCons is a good example of this: for example, currently I have 
> a website completely built from ground-up by SCons, which 
> includes tasks like generating datasets, 3D models, using a PHP 
> filter to generate HTML, running a raytracer to generate 
> images, post-processing generated images, creating a dataset 
> from revision history and rendering graphs, running LaTeX to 
> generate PDF documentation, etc., and installing the products 
> of all of the foregoing into a staging directory that then gets 
> rsync'd to the remote

All of that can be done by any of modern tools with full language 
+ DSL at your disposal, eg Gradle or SBT. In a sense SCons is the 
same but without resolving packages.


> Basically none of these steps involve the traditional 
> invocation of a compiler or built-in source code dependency 
> resolution. SCons has a very nice API for defining my own 
> dependency resolver for custom data formats that can leverage 
> all of the built-in scanning / depending resolving algorithms 
> that come with SCons.
>
> I would not even consider any build system incapable of this 
> level of customization.
>
>
> T