I would rather see it as a convenience. The package is in your store anyway, so better make it available in user shells.
With mysql for example, having the mysql command in your path is not strictly necessary, but it would be really annoying not to have it. Forcing users to install it in their own environments could even lead to version mismatches. If exposing a package from its service happens to be annoying (for whatever reason), may I suggest suggest to pull-request an opt-out option for it ? Le 12/08/16 à 15:44, Moritz Ulrich a écrit : > If the service doesn't provide any necessary command line tools that > would justify putting it into the global environment, I would say it's a > bug, yes. > > > Anders Lundstedt <and...@anderslundstedt.se> writes: > >> On Thu, Aug 11, 2016 at 9:35 PM, Kevin Cox <kevin...@kevincox.ca> wrote: >>> It's also important to not that services generally (never?) actually >>> "install" the package. >> I did a quick check among my enabled services. Two services that add >> their packages to environment.systemPackages are the transmission and >> shairport-sync services. The shairport-sync.nix service file provides >> no motivation for this. Should this be considered a bug? >> _______________________________________________ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev > > > _______________________________________________ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
