Re: nix installed with guix on a foreign distro

[Julien Lepiller]

It's a common limitation of packages that provide a server. Guix doesn't manage 
daemons on foreign distros, it's the role of your distro.

You might be able to set it up by installing as root, maybe manually copy the 
systemd service and hope that's enough. We can't support all methods of running 
daemons there exist on foreign distros, so you're on your own.

Le 27 juillet 2022 00:49:07 GMT+02:00, jgart  a écrit :
>On Tue, 26 Jul 2022 16:16:58 -0500 Nathan Dehnel  wrote:
>> I just installed the nix package provided by the host distro (not
>> guix). Seems to work fine.
>
>Hi Nathan,
>
>I've done that plenty of times before. That's usually how I install nix
>on a foreign distro (i.e. by using apt or xbps (void linux), etc.)
>
>What I'm asking about here is making it easy to install nix with guix on a 
>foreign distro.
>
>Currently, I can do the following on a foreign distro:
>
>`guix install nix`
>
>But the above will not set up the daemon service and create the build users, 
>etc...
>
>So, currently I'm not sure how we should go about supporting that on a foreign 
>distro...
>
>wdyt,
>
>jgart
>

developing javascript with guix

[jgart]

Should we make a guide for developing with js and guix?

For example, how does a js developer use `guix shell` to load a js lib like
node-rimraf in a repl currently?

There's currently no doc for getting started with that iirc

Re: nix installed with guix on a foreign distro

[jgart]

On Tue, 26 Jul 2022 12:10:22 +0200 Maxime Devos  wrote:
> On 26-07-2022 08:00, jgart wrote:
> 
> > Hi Guixers,
> >
> > How can we make it easier to install nix with guix on a foreign distro?
> >
> > Guix System has a nix-service-type but there is no such thing on Debian.
> >
> > wdyt
> 
> This sounds like a question for Nix or Debian people to me, as AFAICT it 
> doesn't concern Guix.

What do you think Debian people should be providing to make it easier to run 
the guix installed nix package?

Or, what should I ask the Debian people if I decide to inquire with them?

all best,

jgart

Re: nix installed with guix on a foreign distro

[jgart]

On Tue, 26 Jul 2022 16:16:58 -0500 Nathan Dehnel  wrote:
> I just installed the nix package provided by the host distro (not
> guix). Seems to work fine.

Hi Nathan,

I've done that plenty of times before. That's usually how I install nix
on a foreign distro (i.e. by using apt or xbps (void linux), etc.)

What I'm asking about here is making it easy to install nix with guix on a 
foreign distro.

Currently, I can do the following on a foreign distro:

`guix install nix`

But the above will not set up the daemon service and create the build users, 
etc...

So, currently I'm not sure how we should go about supporting that on a foreign 
distro...

wdyt,

jgart

nix installed with guix on a foreign distro

[Nathan Dehnel]

I just installed the nix package provided by the host distro (not
guix). Seems to work fine.

Re: Strategy for Zig packages

[Maxime Devos]

On 26-07-2022 20:48, Liliana Marie Prikler wrote:

4. Convince Zig maintainers to perhaps maybe not join the ranks of Rust
et al. and produce reusable shared libraries?


I'd like to clarify that Rust supports shared libraries (*) just fine, 
it's Cargo that insists on source code.


Looking at 
, it 
might be similar with Zig, as that page is about 'the Zig caching 
system' and mentions Zir code, ABIs and objects.


(*) or, at least, rustc's version of static libraries, I haven't tested 
out shared libraries yet except for the first failed attempt; there 
might be problems with monomorphisation and macros or somehing. Some 
libraries, e.g. recent versions of rust-nom, also are written in such a 
way that appears to require LTO optimisation to be efficient, which 
appears to be non-trivial to be compatible with shared libraries without 
extra disk space.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Strategy for Zig packages

[Liliana Marie Prikler]

Am Dienstag, dem 26.07.2022 um 19:56 +0900 schrieb mcsi...@disroot.org:
> In case this has not been discussed before, what shall be the plan
> for interdependent Zig packages in Guix?  On top of my head there are
> a few options:
> 
> 1. Wait until Zig reaches 1.0; it's too soon to decide now.
> 2. Work with Zig maintainers for a standard way to install
>    Zig libraries as source code.  It could be something like
>    ZIG_PKGS where package name is at $ZIG_PKGS/$name.zig,
>    or a file containing all the mappings.
> 3. Wrap the zig command and feed it declared dependency information
>    while waiting for standardization.
4. Convince Zig maintainers to perhaps maybe not join the ranks of Rust
et al. and produce reusable shared libraries?  

I don't think there's a good case to make for reuse via source code
archives (as the only possible way to reuse).  Technically, there's a
similar construct in C++ called header-only library, but if you need
more than one header to implement one, I'd highly question your design
choices.

Cheers

Strategy for Zig packages

[mcsinyx]

Hello Guix,

Coming from Nix, I am considering switching to Guix in long term.
So far, my biggest gripe with nixpkgs culture, i.e. package vendoring,
seems to be well objected by Guix philosophy.

My current goal is to package software I use and/or maintain,
some of which are written in Zig.  Since Zig is still immature and
there is no consensus on downstream packaging, most user applications,
e.g. ncdu or mepo, resorted to only link with C ABI libraries.

Like Go, Zig code is meant to be statically compiled (it is possible
to write libraries with C ABI in Zig, though they fall under the former
category).  Since the language-specific package managers are still
experimental, some projects, e.g. river or blackshades, choose to vendor
libraries as version-control submodules and rely on relative imports.
Zig packages are specified (recursively) via

zig build-* --pkg-begin name path --pkg-end ...

so I suppose the Zig build system can wrap the command appropriately.

The third category is the software using a Zig package manager.
Dependency information should be retrievable from the manifests.

In case this has not been discussed before, what shall be the plan
for interdependent Zig packages in Guix?  On top of my head there are
a few options:

1. Wait until Zig reaches 1.0; it's too soon to decide now.
2. Work with Zig maintainers for a standard way to install
   Zig libraries as source code.  It could be something like
   ZIG_PKGS where package name is at $ZIG_PKGS/$name.zig,
   or a file containing all the mappings.
3. Wrap the zig command and feed it declared dependency information
   while waiting for standardization.

I would love to hear what Guix maintainers' thought on this issue.

All the bests,
McSinyx

Re: nix installed with guix on a foreign distro

[Maxime Devos]

On 26-07-2022 08:00, jgart wrote:


Hi Guixers,

How can we make it easier to install nix with guix on a foreign distro?

Guix System has a nix-service-type but there is no such thing on Debian.

wdyt


This sounds like a question for Nix or Debian people to me, as AFAICT it 
doesn't concern Guix.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature