3 ms·

Then you end up with a program where the users can never trust it to have any given feature. They use it all the time to edit .sgi files, and then install it on

Then you end up with a program where the users can never trust it to have any given feature. They use it all the time to edit .sgi files, and then install it on a new computer, and bam, suddenly, no support for .sgi files. Or even worse, it is used as a dependency in a script, or it is a library linked by another program, but the author can never trust that any given installation has the feature he actually needs. It is a mess. Just don't do it.

amelius 6y ago
Exactly. By the way another thing I've come to hate is configure or make scripts which download stuff. This is really annoying if you want to build self-contained packages. Or if the downloaded material ends up being not available, or if you're not always connected to the internet.
AshamedCaptain 6y ago
The disadvantage is very mild, and the advantage huge (modularity and ability to easily go embedded). If your dependency manager cannot express "program[+feature]", it is your dependency manager's problem.
- user-the-name 6y ago
  I do not know of a single dependency manager out there that can express that.
  - enriquto 6y ago
    > a single dependency manager out there that can express that. If it existed, it would be a nightmare, because features are recursive, and you would end up with fragile monstrosities like foo[+bar[+baz[+qux],+quux]] of course, each variable having version numbers and all
  - JNRowe 6y ago
    ebuilds¹ use essentially that syntax, as does setuptools². Others support that too(nix, bitbake, etc), but I have bookmarks on the first two ;) ¹ https://devmanual.gentoo.org/general-concepts/dependencies/index.html#built-with-use-dependenciesscan https://devmanual.gentoo.org/general-concepts/dependencies/i... ² https://setuptools.readthedocs.io/en/latest/userguide/dependency_management.html#optional-dependencies https://setuptools.readthedocs.io/en/latest/userguide/depend...
  - throw0101a 6y ago
    MacPorts' variants: * https://guide.macports.org/chunked/reference.variants.html https://guide.macports.org/chunked/reference.variants.html * https://guide.macports.org/chunked/using.variants.html https://guide.macports.org/chunked/using.variants.html The default / most common variants have pre-built binaries that are downloaded via a port install, but if you specify something more 'obscure', things are built from source. FreeBSD's Ports also allow for options: * https://docs.freebsd.org/en/books/porters-handbook/#makefile-options https://docs.freebsd.org/en/books/porters-handbook/#makefile... Build-time and run-time dependencies are both handled.
  - Mic92 6y ago
    Nix and guix.
rualca 6y ago
> Then you end up with a program where the users can never trust it to have any given feature. That's the "glass half empty" pov. The "half glass full" pov is that anyone can still use their favourite piece of software even if an obscure and/or useless library is not available to them.

amelius 6y ago

Exactly. By the way another thing I've come to hate is configure or make scripts which download stuff. This is really annoying if you want to build self-contained packages. Or if the downloaded material ends up being not available, or if you're not always connected to the internet.

AshamedCaptain 6y ago

The disadvantage is very mild, and the advantage huge (modularity and ability to easily go embedded). If your dependency manager cannot express "program[+feature]", it is your dependency manager's problem.

user-the-name 6y ago
I do not know of a single dependency manager out there that can express that.
- enriquto 6y ago
  > a single dependency manager out there that can express that. If it existed, it would be a nightmare, because features are recursive, and you would end up with fragile monstrosities like foo[+bar[+baz[+qux],+quux]] of course, each variable having version numbers and all
- JNRowe 6y ago
  ebuilds¹ use essentially that syntax, as does setuptools². Others support that too(nix, bitbake, etc), but I have bookmarks on the first two ;) ¹ https://devmanual.gentoo.org/general-concepts/dependencies/index.html#built-with-use-dependenciesscan https://devmanual.gentoo.org/general-concepts/dependencies/i... ² https://setuptools.readthedocs.io/en/latest/userguide/dependency_management.html#optional-dependencies https://setuptools.readthedocs.io/en/latest/userguide/depend...
- throw0101a 6y ago
  MacPorts' variants: * https://guide.macports.org/chunked/reference.variants.html https://guide.macports.org/chunked/reference.variants.html * https://guide.macports.org/chunked/using.variants.html https://guide.macports.org/chunked/using.variants.html The default / most common variants have pre-built binaries that are downloaded via a port install, but if you specify something more 'obscure', things are built from source. FreeBSD's Ports also allow for options: * https://docs.freebsd.org/en/books/porters-handbook/#makefile-options https://docs.freebsd.org/en/books/porters-handbook/#makefile... Build-time and run-time dependencies are both handled.
- Mic92 6y ago
  Nix and guix.

rualca 6y ago

> Then you end up with a program where the users can never trust it to have any given feature. That's the "glass half empty" pov. The "half glass full" pov is that anyone can still use their favourite piece of software even if an obscure and/or useless library is not available to them.