Re: [Nix-dev] Nixpkgs versioning

[Tomasz Czyż]

I think npm is using that as well (https://docs.npmjs.com/files/package.json
).

+1 for the idea.

2016-03-29 12:33 GMT+00:00 Arseniy Seroka :

> Hi guys. I saw post about guix release and there was introduced a '@'
> delimiter in pkg's name to separate version from name. Maybe we can use it
> in nix too?
>
> --
> Sincerely,
> Arseniy Seroka
>
>
>
> On 29 March 2016 15:30:17 l...@gnu.org wrote:
>
> > We are pleased to announce the release of GNU Guix & GuixSD 0.10.0,
> > representing 2,247 commits by 52 people over 21 weeks.
> >
> >
> > • About
> >
> >   GNU Guix is a transactional package manager for the GNU system.
> >   The Guix System Distribution, GuixSD, is an advanced distribution
> >   of the GNU system.
> >
> >   In addition to standard package management features, Guix supports
> >   transactional upgrades and roll-backs, unprivileged package
> >   management, and per-user profiles.  GuixSD offers a declarative
> >   approach to operating system configuration management and is highly
> >   hackable.  Guix uses low-level mechanisms from the Nix package
> >   manager, except that packages are defined as native Guile modules,
> >   using extensions to the Scheme language.
> >
> >   GuixSD uses the Linux-Libre kernel and the GNU Shepherd init system.
> >   At this stage it can be used on an i686 or x86_64 machine.
> >
> >   It is also possible to use Guix on top of an already installed
> >   GNU/Linux system, including on mips64el and armv7.
> >
> >   https://www.gnu.org/software/guix/
> >
> >
> > • Download
> >
> >   Here are the compressed sources and a GPG detached signature[*]:
> > ftp://alpha.gnu.org/gnu/guix/guix-0.10.0.tar.gz
> > ftp://alpha.gnu.org/gnu/guix/guix-0.10.0.tar.gz.sig
> >
> >   Here are the bootable USB installation images and their signatures[*]:
> > ftp://alpha.gnu.org/gnu/guix/guixsd-usb-install-0.10.0.i686-linux.xz
> >
> ftp://alpha.gnu.org/gnu/guix/guixsd-usb-install-0.10.0.i686-linux.xz.sig
> >
> ftp://alpha.gnu.org/gnu/guix/guixsd-usb-install-0.10.0.x86_64-linux.xz
> >
> ftp://alpha.gnu.org/gnu/guix/guixsd-usb-install-0.10.0.x86_64-linux.xz.sig
> >
> >   Here are the binary tarballs and their signatures[*]:
> > ftp://alpha.gnu.org/gnu/guix/guix-binary-0.10.0.i686-linux.tar.xz
> >
> ftp://alpha.gnu.org/gnu/guix/guix-binary-0.10.0.i686-linux.tar.xz.sig
> > ftp://alpha.gnu.org/gnu/guix/guix-binary-0.10.0.x86_64-linux.tar.xz
> >
> ftp://alpha.gnu.org/gnu/guix/guix-binary-0.10.0.x86_64-linux.tar.xz.sig
> >
> ftp://alpha.gnu.org/gnu/guix/guix-binary-0.10.0.mips64el-linux.tar.xz
> >
> ftp://alpha.gnu.org/gnu/guix/guix-binary-0.10.0.mips64el-linux.tar.xz.sig
> > ftp://alpha.gnu.org/gnu/guix/guix-binary-0.10.0.armhf-linux.tar.xz
> >
> ftp://alpha.gnu.org/gnu/guix/guix-binary-0.10.0.armhf-linux.tar.xz.sig
> >
> >   Use a mirror for higher download bandwidth:
> > http://www.gnu.org/order/ftp.html
> >
> >   Here are the SHA1 checksums:
> >
> >   36be27ea1f1314d508bd80c84cadf7eafe974093  guix-0.10.0.tar.gz
> >   8e78a5d4b57790fc2b9290c4c1f81d74ba540e28
> guix-binary-0.10.0.armhf-linux.tar.xz
> >   749f04ed6efeb338d7397deb40c836c4ee4d07be
> guix-binary-0.10.0.i686-linux.tar.xz
> >   a04ef4edbfb9592ff8ea301780e7ec7dbc18a22a
> >   guix-binary-0.10.0.mips64el-linux.tar.xz
> >   ec0942aed4370a700880ffd9793615c2968729c6
> >   guix-binary-0.10.0.x86_64-linux.tar.xz
> >   804e27fa18c3728eb44602181b99c187fcc8e5ce
> >   guixsd-usb-install-0.10.0.i686-linux.xz
> >   2fe38e43951f9aa5caa87d743757bdc110c38377
> >   guixsd-usb-install-0.10.0.x86_64-linux.xz
> >
> >   [*] Use a .sig file to verify that the corresponding file (without the
> >   .sig suffix) is intact.  First, be sure to download both the .sig file
> >   and the corresponding tarball.  Then, run a command like this:
> >
> > gpg --verify guix-0.10.0.tar.gz.sig
> >
> >   If that command fails because you don't have the required public key,
> >   then run this command to import it:
> >
> > gpg --keyserver keys.gnupg.net --recv-keys 3D9AEBB5
> >
> >   and rerun the 'gpg --verify' command.
> >
> >   This release was bootstrapped with the following tools:
> > Autoconf 2.69
> > Automake 1.15
> > Makeinfo 6.1
> > Help2man 1.47.3
> >
> >   To install the Guix System Distribution, please see “System
> >   Installation” in the manual.  To install Guix on a running
> >   system, see “Installation” in the manual.
> >
> >
> > • Changes since version 0.9.0 (excerpt from the NEWS file)
> >
> >   ** Community
> >
> >   GNU Guix adopted a contributor code of conduct, see ‘CODE-OF-CONDUCT’
> in the
> >   source tree.
> >
> >   ** Package management
> >
> >   *** New command-line syntax for separating package names and version
> numbers
> >
> >   Use ‘@’ instead of ‘-’ as a separator, as in ‘gnupg@2.0’.  This new
> separator
> >   is a reserved character which is not allowed both in package names and
> version
> >   numbers.
> >
> >   The old syntax to specify a package’s 

Re: [Nix-dev] Nixpkgs versioning

[Tomasz Czyż]

I would say it maybe doesn't matter for main nix repo and nixpkgs. But when
you have your development platform with private packages this can be an
issue.

I have the situation now where I have one repo with private packages but
for different projects I use different versions of the same package.

I could use totally separated dependencies per project, but for some cases
I prefer to use central repo (to avoid repetitions mostly) and in that case
I need package versioning (I'm using _ right now
which is not that convininet).

2016-03-30 23:18 GMT+00:00 Colin Putney :

>
> > On Mar 30, 2016, at 1:55 AM, Jakob Gillich  wrote:
> >
> > FYI npm also uses @ for this purpose (e.g. npm install foo@1.0). I don't
> > think I ever had to escape it (?).
>
> I don’t know about Guix, but with NPM, version names are much more
> important than they are with nix. NPM uses semver and constraint solving to
> resolve dependencies based on the version numbers, so the actual x.y.z
> number attached to a given release is critical. With nix, there’s no
> central registry of packages, release and their numbers, and we often
> specify dependencies with a Git rev and hash. We use fixed-output
> derivations to ensure that we always get the right dependency, so the
> version number of a given derivation doesn’t matter that much, and often
> doesn’t exist.
>
> Colin
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>



-- 
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nixpkgs versioning

[Colin Putney]

> On Mar 30, 2016, at 1:55 AM, Jakob Gillich  wrote:
> 
> FYI npm also uses @ for this purpose (e.g. npm install foo@1.0). I don't
> think I ever had to escape it (?).

I don’t know about Guix, but with NPM, version names are much more important 
than they are with nix. NPM uses semver and constraint solving to resolve 
dependencies based on the version numbers, so the actual x.y.z number attached 
to a given release is critical. With nix, there’s no central registry of 
packages, release and their numbers, and we often specify dependencies with a 
Git rev and hash. We use fixed-output derivations to ensure that we always get 
the right dependency, so the version number of a given derivation doesn’t 
matter that much, and often doesn’t exist.

Colin
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nixpkgs versioning

[Tomasz Czyż]

2016-03-30 17:31 GMT+00:00 Vladimír Čunát :

> On 03/30/2016 04:42 PM, Tomasz Czyż wrote:
> > There is any rule for transforming app name + version to attribute name?
>
> None AFAIK. And there's a related rule to strive to avoid using multiple
> versions and avoid specifying the version in attribute name at all.
>
 Yeah, but I assume we are talking about examples like you wrote, llvm_37

>
> --Vladimir
>
>
>


-- 
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nixpkgs versioning

[Vladimír Čunát]

On 03/30/2016 04:42 PM, Tomasz Czyż wrote:
> There is any rule for transforming app name + version to attribute name?

None AFAIK. And there's a related rule to strive to avoid using multiple
versions and avoid specifying the version in attribute name at all.

--Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nixpkgs versioning

[Vladimír Čunát]

On 03/30/2016 12:02 PM, Peter Simons wrote:
> Besides, I thought the universally agreed best way forward was to drop
> the notion of installing packages "by name" from the CLI anyway?

True, we push towards using attribute names instead. There can be
version embedded in attribute names, e.g. we have llvm_37, but `@` makes
little sense in there...

--Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nixpkgs versioning

[Vladimír Čunát]

On 03/30/2016 11:35 AM, Peter Simons wrote:
> I thought the universally agreed best way forward was to keep the
> version number in a separate $version attribute anyway?

That doesn't seem to address disambiguation on the command-line.

--Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nixpkgs versioning

[Peter Simons]

I thought the universally agreed best way forward was to keep the
version number in a separate $version attribute anyway?

Best regards,
Peter

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

Re: [Nix-dev] Nixpkgs versioning

[Vladimír Čunát]

On 03/30/2016 10:55 AM, Jakob Gillich wrote:
> FYI npm also uses @ for this purpose (e.g. npm install foo@1.0). I don't
> think I ever had to escape it (?).

Oh, thanks! I'm sorry, I confused it with something else.

--Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nixpkgs versioning

[Jakob Gillich]

FYI npm also uses @ for this purpose (e.g. npm install foo@1.0). I don't
think I ever had to escape it (?).

On Wed, Mar 30, 2016, at 10:32 AM, Vladimír Čunát wrote:
> On 03/29/2016 02:33 PM, Arseniy Seroka wrote:
> > I saw post about guix release and there was introduced a '@' 
> > delimiter in pkg's name to separate version from name. Maybe we can use it 
> > in nix too?
> 
> It seems rather unconventional and currently I can't see enough
> advantages to convince me personally.
> 
> In shell commands you will typically need to escape the character, which
> would affect commands like `nix-env -i foo\@ver` but that shouldn't
> happen too often. What would be worse, if this delimiter was used in
> filesystem paths like /nix/store/hash-fooname@version/... we would have
> to escape all of the occurrences and I'd expect many scripts to break.
> 
> --Vladimir
> 
> 
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> Email had 1 attachment:
> + smime.p7s
>   5k (application/pkcs7-signature)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nixpkgs versioning

[Vladimír Čunát]

On 03/29/2016 02:33 PM, Arseniy Seroka wrote:
> I saw post about guix release and there was introduced a '@' 
> delimiter in pkg's name to separate version from name. Maybe we can use it 
> in nix too?

It seems rather unconventional and currently I can't see enough
advantages to convince me personally.

In shell commands you will typically need to escape the character, which
would affect commands like `nix-env -i foo\@ver` but that shouldn't
happen too often. What would be worse, if this delimiter was used in
filesystem paths like /nix/store/hash-fooname@version/... we would have
to escape all of the occurrences and I'd expect many scripts to break.

--Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev