RejectedSoftware Forums

On Mon, 20 Oct 2014 09:05:28 +0200, Sönke Ludwig wrote:

Am 12.10.2014 12:16, schrieb Angst:

[Subject], is it possible?
That way it might be easier to select all vibe.d plugins.

That's an interesting idea, might make sense to add a section to each
package's page with all dependent packages.

Also, ordering by "Most Depended Upon" might be nice.

I wanted to add this, or a combination with the download numbers as
"sort by popularity". I'm not sure when I'll get to that, though, as my
time for the open source projects will be extremely limited for the next
two or three months.

Looking forward to the next three to four months ;)

Wow, we have some catching up to do ;P

Node Packaged Modules
Total Packages: 99 528
https://www.npmjs.org/

That's true, but if the (almost) exponential growth continues, we should
get some more impressive numbers in the not too distant future. But it's
the question if the number of packages is a good performance measure for
a package eco system. At least I would hope that D packages will have a
higher complexity (in the sense of amount of functionality) than the
average node.js package. Too many of those 100.000 packages are
absolutely trivial pieces of code.

Don't underestimate the usefulness of trivial/small pieces of code!

Take the grunt plugins:
http://gruntjs.com/plugins

You could classify a lot of these node modules as trivial: actual code (excluding tests) being around 100 lines. But they are well tested and without them grunt would not be possible.

Standing on tiny shoulders is still nice ;)

On Tue, 21 Oct 2014 10:38:14 +0200, Sönke Ludwig wrote:

Am 20.10.2014 18:12, schrieb Angst:

(...)

Don't underestimate the usefulness of trivial/small pieces of code!

Take the grunt plugins:
http://gruntjs.com/plugins

You could classify a lot of these node modules as trivial: actual code (excluding tests) being around 100 lines. But they are well tested and without them grunt would not be possible.

Standing on tiny shoulders is still nice ;)

Sure, but it also comes at a cost:

Let me reply from my limited experience with npm front-end web dev.

• Selecting the right package may cost more time than writing the code

itself if there are many alternatives

"Search by popularity/starred"-on-by-default seems to fix this problem for grunt.
Become the most used module or die in the long-tail.

• It increases the chance for unintended license violations when

different licenses are involved and a project has dozens of dependencies

There is a module for that:
https://www.npmjs.org/package/license-checker

But on a whole people tend to not really care and expect everything to be MIT or something alike.

• It increases the chance for version conflicts when e.g.

"trivial-pack-a" depends on the same dependency "pack-c" as
"trivial-pack-b" (maybe indirectly), but accepts a different
version(range) for that package

Npm solves this by making all dependencies local:
project/nodemodules/module/nodemodules/depmodule/nodemodules/depdepmodule/...
or, in your case:
project/nodemodules/trivial-pack-a/nodemodules/pack-c(0.1)
project/nodemodules/trivial-pack-b/nodemodules/pack-c(0.2)

• It increases the maintenance friction (e.g. you have to wait for all

dependencies to fix compilation on the latest DMD version and you may)

I am not sure how much of a problem this is for npm.
Personally I haven't had any such problems but I haven't been using npm that long either.
Could be a real problem for D(UB).

So it's a nice thing to have in principle, especially for rapid
prototyping, but I'd definitely rather prefer a library that manages a
bunch of trivialities under one umbrella to avoid the above issues.
There are always exceptions of course, though!

If search-by-popularity would be on by default and most people agree with your mindset, then all the trivial modules would die in the long-tail. But first, lets give the trivial modules and giants a place to have a real fight ;)

At least with the new "dub.selections.json" feature, DUB should be well
prepared for managing large dependency hierarchies.

On Tue, 21 Oct 2014 15:37:59 +0200, Sönke Ludwig wrote:

Am 21.10.2014 15:22, schrieb Angst:

On Tue, 21 Oct 2014 10:38:14 +0200, Sönke Ludwig wrote:

Am 20.10.2014 18:12, schrieb Angst:

(...)

Don't underestimate the usefulness of trivial/small pieces of code!

Take the grunt plugins:
http://gruntjs.com/plugins

You could classify a lot of these node modules as trivial: actual code (excluding tests) being around 100 lines. But they are well tested and without them grunt would not be possible.

Standing on tiny shoulders is still nice ;)

Sure, but it also comes at a cost:

Let me reply from my limited experience with npm front-end web dev.

• Selecting the right package may cost more time than writing the code
  itself if there are many alternatives

"Search by popularity/starred"-on-by-default seems to fix this problem for grunt.
Become the most used module or die in the long-tail.

I personally haven't done much in this direction, but I've read some
postmortems where the developers have gone through a number of packages,
only to discover that they'd better written the code themselves from the
start. But you are right of course, it always depends a lot on the
concrete case.

• It increases the chance for unintended license violations when
  different licenses are involved and a project has dozens of dependencies

There is a module for that:
https://www.npmjs.org/package/license-checker

But on a whole people tend to not really care and expect everything to be MIT or something alike.

It's loosely planned to integrate a license checker directly into DUB.
This will hopefully avoid this issue for the most part.

• It increases the chance for version conflicts when e.g.
  "trivial-pack-a" depends on the same dependency "pack-c" as
  "trivial-pack-b" (maybe indirectly), but accepts a different
  version(range) for that package

Npm solves this by making all dependencies local:
project/nodemodules/module/nodemodules/depmodule/nodemodules/depdepmodule/...
or, in your case:
project/nodemodules/trivial-pack-a/nodemodules/pack-c(0.1)
project/nodemodules/trivial-pack-b/nodemodules/pack-c(0.2)

Unfortunately this won't work for D, as it may result in both compiler
errors (conflicting imports) and linker errors (duplicate symbols).

Would be nice though :)

• It increases the maintenance friction (e.g. you have to wait for all
  dependencies to fix compilation on the latest DMD version and you may)

I am not sure how much of a problem this is for npm.
Personally I haven't had any such problems but I haven't been using npm that long either.
Could be a real problem for D(UB).

Yeah, at least the language is stable in case of NPM. But it also
applies to the underlying libraries. For example if vibe.d introduces
breaking changes and several libraries rely on different versions of it.
Of course this is an issue even for bigger libraries, but the chances of
conflicts increase with the number of dependencies.

So it's a nice thing to have in principle, especially for rapid
prototyping, but I'd definitely rather prefer a library that manages a
bunch of trivialities under one umbrella to avoid the above issues.
There are always exceptions of course, though!

If search-by-popularity would be on by default and most people agree with your mindset, then all the trivial modules would die in the long-tail. But first, lets give the trivial modules and giants a place to have a real fight ;)

Well, my hope and reality aren't necessarily the same thing, so I'm sure
that there will be enough small packages ;)

Looking forward to the "monthly downloads" column on code.dlang.org ;)