Re: [Nix-dev] Two declarative ways to install a package?

[Guillaume Maudoux (Layus)]

Le 12 août 2016 18:02:49 UTC+02:00, Arnold Krille  a 
écrit :
>On Fri, 12 Aug 2016 16:15:46 +0200 "Guillaume Maudoux (Layus)"
> wrote:
>> I would rather see it as a convenience.
>> The package is in your store anyway, so better make it available in
>> user shells.
>
>No, only expose what is needed or wanted explicit (explicit is better
>then implicit;-)). Just because I want mpd to run on my machine,
>doesn't mean I want every user to run its own mpd (and wonder why the
>default-port is already in use). For example.
>

I guess m'y use cases are only single-user machines, where the difference 
between user and system is sometimes fuzzy.

>> 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.
>
>This largely depends on the package, doesn't it?
>
>For the mysql-service to expose the mysql-commandline tool is a nice
>convenience, at the same time exposing the mysqld binary is needless
>and allows other apps to use that binary without actually depending on
>it. It also allows foes to use it directly from your environment
>without dealing specially with nix.
>
>For the nginx-package to expose the nginx-daemon binary to your
>environment isa bit useless for the same reasons explained with mysqld
>exposed. But are there user-tools for nginx that should be exposed?
>
>Maybe it would be better if there was a mysql and a mysql-server
>package and the mysql-service would use the mysql-server itself and
>expose the mysql commandline to the environment without exposing the
>server binary?
>
>> 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 ?
>
>For security and sanity reason, it should be opt-in.

I think your point ils valid. But an option is not so useful in this case. 
Adding the package to the environment directly may even be simpler than 
enabling the option.

Oh btw, What would you think of a global opt-in option ? Like noXLibs ?

>
>- Arnold
>
>
>
>
>___
>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

Re: [Nix-dev] Two declarative ways to install a package?

[Arnold Krille]

On Fri, 12 Aug 2016 16:15:46 +0200 "Guillaume Maudoux (Layus)"
 wrote:
> I would rather see it as a convenience.
> The package is in your store anyway, so better make it available in
> user shells.

No, only expose what is needed or wanted explicit (explicit is better
then implicit;-)). Just because I want mpd to run on my machine,
doesn't mean I want every user to run its own mpd (and wonder why the
default-port is already in use). For example.

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

This largely depends on the package, doesn't it?

For the mysql-service to expose the mysql-commandline tool is a nice
convenience, at the same time exposing the mysqld binary is needless
and allows other apps to use that binary without actually depending on
it. It also allows foes to use it directly from your environment
without dealing specially with nix.

For the nginx-package to expose the nginx-daemon binary to your
environment isa bit useless for the same reasons explained with mysqld
exposed. But are there user-tools for nginx that should be exposed?

Maybe it would be better if there was a mysql and a mysql-server
package and the mysql-service would use the mysql-server itself and
expose the mysql commandline to the environment without exposing the
server binary?

> 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 ?

For security and sanity reason, it should be opt-in.

- Arnold


signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Two declarative ways to install a package?

[Guillaume Maudoux (Layus)]

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  writes:
>
>> On Thu, Aug 11, 2016 at 9:35 PM, Kevin Cox  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

Re: [Nix-dev] Two declarative ways to install a package?

[Moritz Ulrich]

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  writes:

> On Thu, Aug 11, 2016 at 9:35 PM, Kevin Cox  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

-- 


signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Two declarative ways to install a package?

[Roger Qiu]

For example: There are both nginx package and nginx service. The package
part is just the package management aspect of Nix, while the nginx service
is the service management (configuration management) aspect of Nix. However
if you use the service, then as a dependency, package is usually installed.
On 12/08/2016 5:11 AM, "Nick Sabalausky" 
wrote:

> I'm noticing that when installing packages declaratively via
> configuration.nix and nixos-rebuild, some packages are install one way, but
> others are installed another way. For example:
>
> # Some packages are installed via environment.systemPackages
> environment.systemPackages = with pkgs; [
>   wget firefox thunderbird git
> ];
>
> # Others are installed via *.enabled = true;
> services.openssh.enable = true;
> services.printing.enable = true;
> services.xserver.enable = true;
> services.xserver.displayManager.kdm.enable = true;
> services.xserver.desktopManager.kde4.enable = true;
> services.vmwareGuest.enable = true;
>
> What exactly is the difference? Is there any more nuance to it than
> "Services are installed one way, non-services are installed the other way"?
>
> How do I know which way to install a given package? Especially if I'm not
> sure offhand whether a given package involves a service component.
>
> Can all packages be installed wither way? Are all packages ONLY one way or
> the other?
>
> How can I find what packages are available via one method or the other?
> ___
> 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

Re: [Nix-dev] Two declarative ways to install a package?

[Anders Lundstedt]

On Thu, Aug 11, 2016 at 9:35 PM, Kevin Cox  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

Re: [Nix-dev] Two declarative ways to install a package?

[Kevin Cox]

On 11/08/16 20:11, Nick Sabalausky wrote:
> 
> What exactly is the difference? Is there any more nuance to it than
> "Services are installed one way, non-services are installed the other way"?
> 


Basically the services are wrappers around the packages. They set them
up, generate config files and set them to start running.

It's also important to not that services generally (never?) actually
"install" the package. Obviously it is on the system but it isn't
available on your PATH.

Hope that helps, Kevin



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Two declarative ways to install a package?

[Nick Sabalausky]

I'm noticing that when installing packages declaratively via 
configuration.nix and nixos-rebuild, some packages are install one way, 
but others are installed another way. For example:


# Some packages are installed via environment.systemPackages
environment.systemPackages = with pkgs; [
  wget firefox thunderbird git
];

# Others are installed via *.enabled = true;
services.openssh.enable = true;
services.printing.enable = true;
services.xserver.enable = true;
services.xserver.displayManager.kdm.enable = true;
services.xserver.desktopManager.kde4.enable = true;
services.vmwareGuest.enable = true;

What exactly is the difference? Is there any more nuance to it than 
"Services are installed one way, non-services are installed the other way"?


How do I know which way to install a given package? Especially if I'm 
not sure offhand whether a given package involves a service component.


Can all packages be installed wither way? Are all packages ONLY one way 
or the other?


How can I find what packages are available via one method or the other?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev