Re: [Nix-dev] Using Nix as the preferred package manager for a new language

[Roger Qiu]

There's some work on Nix on Windows:

* https://nixos.org/wiki/Nix_on_Windows
* https://ternaris.com/lab/nix-on-windows.html

On 13/02/2016 12:01 AM, Philipp Hausmann wrote:

Interestingly enough, we have some of the same questions for the Agda
programming language. Currently, Agda doesn't really have any package
manager, so there are no backwards-compatibility problems with using Nix.

It would be really nice if we could use Nix as the one-and-only package
management solution for Agda. However, Nix doesn't support Windows,
which means we need a second fallback solution. This is rather
unpleasant, but not a show stopper.

For Agda, I'm currently leaning towards defining a simple package json
format and a very basic build tool and to build Nix support on top of
that. Kind of like the Haskell packages.

I'm certainly interested in how you're solving this problems and I will
keep an eye on it, maybe I can steal some of your work and use it for
Agda ;-)

Cheers, Philipp


Hi! I've tried to start this discussion a couple times on IRC, but it
hasn't really gotten attention, so:

I'm one of the developers of Monte, a new programming language. We don't
want to write a package manager, because package managers are hard. (Also
we've been watching npm happen for the past few years.) So we plan to use
Nix. However, we've got some requirements for our package layout, and we
haven't seen anybody else do all of the things we want at once. Here's
what we're thinking:

* Monte packages shouldn't live in nixpkgs. We use standalone Nix
expressions to build stuff like our runtime, and it makes development very
speedy since we do not have to round-trip our Nix changes through nixpkgs.
We also want to keep Nix expressions for packages close to the packages
themselves (see next point.) Perhaps when our ecosystem has developed
more, we can revisit this.

* Monte packages should bundle their own Nix expressions. Our reasoning is:

** Suppose that we have some "mtpkgs" tree, which is like nixpkgs but only
contains a Nix expression for building some or all of the Monte runtime
and packages. However, now we've decoupled the description of the packages
from the packages themselves, which makes maintaining the package harder,
since changes to the package require a corresponding change to mtpkgs. We
didn't gain anything over just using nixpkgs!

** Okay, so instead we make a JSON (or whatever) description of each
package, and ship that with the package. Then, we interpret that
description as a Nix expression, and do Nix things as usual. Except that
this doesn't work, because now the JSON description is a new package
manager format! We didn't want that.

** So it seems like packages should ship with a Nix expression.

* Packages should be easy to cargo-cult. This might sound weird, but my
experience in other ecosystems (especially Python and Perl) has taught me
that most package descriptions are cargo-culted from other similar
packages. We should have a very custom Nix derivation-producing function
which turns a minimal Nix expression into a full Monte package
description.

So with that in mind, here's where we currently are. We have a runtime and
some packages. There's a terrible terrible Nix function that generates
derivations (
https://github.com/monte-language/typhon/blob/master/default.nix#L11-L34
). An example usage is (
https://github.com/monte-language/mt-rational/blob/master/default.nix ).

As you can see, our derivations are not especially good. We don't have a
good way to locate a runtime so that we can call ``montePackage`` easily.
Once our packages start depending on other Monte packages, the problem
will only be worse. We also have this indirect dependency on nixpkgs for
library stuff, which is worse than a direct dependency or no dependency at
all.

We're seeking any advice on how to make this situation better. As far as
we can tell, nobody else has tried to make Nix their first-class preferred
package management solution for their language, so we are blazing trails
here.

Thanks!
~ C.



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


--
Founder of Matrix AI
https://matrix.ai/
+61420925975

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

Re: [Nix-dev] Using Nix as the preferred package manager for a new language

[Philipp Hausmann]

Interestingly enough, we have some of the same questions for the Agda
programming language. Currently, Agda doesn't really have any package
manager, so there are no backwards-compatibility problems with using Nix.

It would be really nice if we could use Nix as the one-and-only package
management solution for Agda. However, Nix doesn't support Windows,
which means we need a second fallback solution. This is rather
unpleasant, but not a show stopper.

For Agda, I'm currently leaning towards defining a simple package json
format and a very basic build tool and to build Nix support on top of
that. Kind of like the Haskell packages.

I'm certainly interested in how you're solving this problems and I will
keep an eye on it, maybe I can steal some of your work and use it for
Agda ;-)

Cheers, Philipp

> Hi! I've tried to start this discussion a couple times on IRC, but it
> hasn't really gotten attention, so:
>
> I'm one of the developers of Monte, a new programming language. We don't
> want to write a package manager, because package managers are hard. (Also
> we've been watching npm happen for the past few years.) So we plan to use
> Nix. However, we've got some requirements for our package layout, and we
> haven't seen anybody else do all of the things we want at once. Here's
> what we're thinking:
>
> * Monte packages shouldn't live in nixpkgs. We use standalone Nix
> expressions to build stuff like our runtime, and it makes development very
> speedy since we do not have to round-trip our Nix changes through nixpkgs.
> We also want to keep Nix expressions for packages close to the packages
> themselves (see next point.) Perhaps when our ecosystem has developed
> more, we can revisit this.
>
> * Monte packages should bundle their own Nix expressions. Our reasoning is:
>
> ** Suppose that we have some "mtpkgs" tree, which is like nixpkgs but only
> contains a Nix expression for building some or all of the Monte runtime
> and packages. However, now we've decoupled the description of the packages
> from the packages themselves, which makes maintaining the package harder,
> since changes to the package require a corresponding change to mtpkgs. We
> didn't gain anything over just using nixpkgs!
>
> ** Okay, so instead we make a JSON (or whatever) description of each
> package, and ship that with the package. Then, we interpret that
> description as a Nix expression, and do Nix things as usual. Except that
> this doesn't work, because now the JSON description is a new package
> manager format! We didn't want that.
>
> ** So it seems like packages should ship with a Nix expression.
>
> * Packages should be easy to cargo-cult. This might sound weird, but my
> experience in other ecosystems (especially Python and Perl) has taught me
> that most package descriptions are cargo-culted from other similar
> packages. We should have a very custom Nix derivation-producing function
> which turns a minimal Nix expression into a full Monte package
> description.
>
> So with that in mind, here's where we currently are. We have a runtime and
> some packages. There's a terrible terrible Nix function that generates
> derivations (
> https://github.com/monte-language/typhon/blob/master/default.nix#L11-L34
> ). An example usage is (
> https://github.com/monte-language/mt-rational/blob/master/default.nix ).
>
> As you can see, our derivations are not especially good. We don't have a
> good way to locate a runtime so that we can call ``montePackage`` easily.
> Once our packages start depending on other Monte packages, the problem
> will only be worse. We also have this indirect dependency on nixpkgs for
> library stuff, which is worse than a direct dependency or no dependency at
> all.
>
> We're seeking any advice on how to make this situation better. As far as
> we can tell, nobody else has tried to make Nix their first-class preferred
> package management solution for their language, so we are blazing trails
> here.
>
> Thanks!
> ~ C.



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

Re: [Nix-dev] Using Nix as the preferred package manager for a new language

[Игорь Пашев]

If you don't want a new package manager, why a new language?
10 февр. 2016 г. 0:40 пользователь  написал:

> Hi! I've tried to start this discussion a couple times on IRC, but it
> hasn't really gotten attention, so:
>
> I'm one of the developers of Monte, a new programming language. We don't
> want to write a package manager, because package managers are hard. (Also
> we've been watching npm happen for the past few years.) So we plan to use
> Nix. However, we've got some requirements for our package layout, and we
> haven't seen anybody else do all of the things we want at once. Here's
> what we're thinking:
>
> * Monte packages shouldn't live in nixpkgs. We use standalone Nix
> expressions to build stuff like our runtime, and it makes development very
> speedy since we do not have to round-trip our Nix changes through nixpkgs.
> We also want to keep Nix expressions for packages close to the packages
> themselves (see next point.) Perhaps when our ecosystem has developed
> more, we can revisit this.
>
> * Monte packages should bundle their own Nix expressions. Our reasoning is:
>
> ** Suppose that we have some "mtpkgs" tree, which is like nixpkgs but only
> contains a Nix expression for building some or all of the Monte runtime
> and packages. However, now we've decoupled the description of the packages
> from the packages themselves, which makes maintaining the package harder,
> since changes to the package require a corresponding change to mtpkgs. We
> didn't gain anything over just using nixpkgs!
>
> ** Okay, so instead we make a JSON (or whatever) description of each
> package, and ship that with the package. Then, we interpret that
> description as a Nix expression, and do Nix things as usual. Except that
> this doesn't work, because now the JSON description is a new package
> manager format! We didn't want that.
>
> ** So it seems like packages should ship with a Nix expression.
>
> * Packages should be easy to cargo-cult. This might sound weird, but my
> experience in other ecosystems (especially Python and Perl) has taught me
> that most package descriptions are cargo-culted from other similar
> packages. We should have a very custom Nix derivation-producing function
> which turns a minimal Nix expression into a full Monte package
> description.
>
> So with that in mind, here's where we currently are. We have a runtime and
> some packages. There's a terrible terrible Nix function that generates
> derivations (
> https://github.com/monte-language/typhon/blob/master/default.nix#L11-L34
> ). An example usage is (
> https://github.com/monte-language/mt-rational/blob/master/default.nix ).
>
> As you can see, our derivations are not especially good. We don't have a
> good way to locate a runtime so that we can call ``montePackage`` easily.
> Once our packages start depending on other Monte packages, the problem
> will only be worse. We also have this indirect dependency on nixpkgs for
> library stuff, which is worse than a direct dependency or no dependency at
> all.
>
> We're seeking any advice on how to make this situation better. As far as
> we can tell, nobody else has tried to make Nix their first-class preferred
> package management solution for their language, so we are blazing trails
> here.
>
> Thanks!
> ~ C.
>
> ___
> 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] Using Nix as the preferred package manager for a new language

[stewart mackenzie]

Hi Thomas, (I'm unsure who you were addressing :-) but here's my response)
 I've been studying Peter and Gleb's work. This function is a thing of
beauty: [1]

On Wed, Feb 10, 2016 at 7:14 PM, Thomas Hunger  wrote:
> I think the idea is exciting but difficult. Some notes / questions:
>
> 1/ Nix stores its data in /nix/store - is your package manager OK with root
> access? There are ways around that, e.g. using --with-store-dir but see [-1].

Well so far nix is our package manager.. it is our.. everything..
Where one considers a package as a shared library exposing a C ABI.
Nix literally glues everything together.
Nix builds each component and at the final step composes some six to
eight of those components forming the virtual machine, which can
execute fbp markup.
So we have really deep integration with nix. (It's really great when
nix catches circular dependencies...).

Now Rok's idea is to have a vm wrapper nix expression which
recursively parses the argument fbp file and builds a virtual machine
with exactly those deps. At this stage I really like this approach, it
keeps everything nix and riding on the goodness of the nix community
as well as contributing back, but of course it means fractalide has a
hard dependency on nix, which given the design goals of a system
coordinator and high level monitoring system. How else is one going to
have such deep control over a system?

> 2/ Do you want semver versioning or some form of always-follow-HEAD with
> stabilization branches like e.g. nixos or stackage LTS do?

I really don't want to follow the semver approach and instead will
annotate a component's inputs and outputs with a stability factor [2]
(still vapourware atm)
Whatever is on head should be (re-)usable. There should be no
stabilization branches, every single component should be completely
reusable right out the gates.
- component names are stable and do not change (unless every port is
experimental)
- port names remain stable and are never* renamed or deleted (* only
when the port in question isn't "experimental")
- capnproto contracts on each port must evolve (using capnproto
features) allowing for backward compatibility.
Eventually I'd really like to have a bit of code to map-reduce over
the port connection graph to determine what's being used to
automatically annotate ports... and most importantly who breaks the
contracts. My goal is rock solid software one could sign stability SLA
agreements on.

> 3/ Will you ever bind to c libraries like postgresql?

For trivial things like a component wrapping Iron (a rust webserver on
crates.io) which needs openssl to build, it's not a problem [3].
But when it comes to setting up more complex components such as
postgres which requires service activation I see a problem with this
approach.
It's at this point where I'd say going the guix approach might be best
but I'm a noob so I don't know. It's a design goal to enable complex
components which would setup services and configure a running
system... eventually I'd like it to setup across a network barrier. I
need to think about this more... it's still on the horizon, riding nix
as much as possible would be best.

The frontend (vapourware atm) will be a hypercard reimplementation,
input starts there (or cli) and flows through a system as complex as
fbp components on nixpkgs eventually back again - maybe it's useful.

> If you can fall back on binaries from your underlying system then maybe 1
> isn't a problem - at the cost of reproducibility.

Rust compile times are super slow to the point of annoying, so binary
distribution is a must, though the end goal is binary distribution
over a named data network, that's why _everything_ is build from named
components.

> Personally I think I'd follow Domen's advice of machine readable metadata
> and convert those into one big nix-expression on the fly before running e.g.
> nix-build.
> There are already several good examples for packaging *all* libraries for an
> ecosystem from metadata (Peter's excellent Haskell work, Gleb's hex
> packages, ...).

Actually I really like Domen's advice an a good specification of
packaging metadata with neat functions to convert to and from.

Though i think my mileage is pretty far given that 1) nix is going to
become more portable (via shealevy's awesome work) 2) nix has become a
super huge monster that lazily evaluates, it would be really sad to
depart from nix 3) a nix file that's as simple as this [3] isn't too
bad.

the `src` bit can be replaced with a fetchgit or something like that
so folks can develop elsewhere if needed.

> [-1]
> A while ago I spent some time trimming down nix to just stdenv.mkDerivation
> + lib + {git,svn,url} fetchers so I could use it as "import 
> {}". Rebuilding that with a different --with-store-dir still takes a long
> time (using a path other than /nix/store disables binary substitution).

I really must look into this! Seems like awesome work!

[1] 

[Nix-dev] Using Nix as the preferred package manager for a new language

[cds]

Hi! I've tried to start this discussion a couple times on IRC, but it
hasn't really gotten attention, so:

I'm one of the developers of Monte, a new programming language. We don't
want to write a package manager, because package managers are hard. (Also
we've been watching npm happen for the past few years.) So we plan to use
Nix. However, we've got some requirements for our package layout, and we
haven't seen anybody else do all of the things we want at once. Here's
what we're thinking:

* Monte packages shouldn't live in nixpkgs. We use standalone Nix
expressions to build stuff like our runtime, and it makes development very
speedy since we do not have to round-trip our Nix changes through nixpkgs.
We also want to keep Nix expressions for packages close to the packages
themselves (see next point.) Perhaps when our ecosystem has developed
more, we can revisit this.

* Monte packages should bundle their own Nix expressions. Our reasoning is:

** Suppose that we have some "mtpkgs" tree, which is like nixpkgs but only
contains a Nix expression for building some or all of the Monte runtime
and packages. However, now we've decoupled the description of the packages
from the packages themselves, which makes maintaining the package harder,
since changes to the package require a corresponding change to mtpkgs. We
didn't gain anything over just using nixpkgs!

** Okay, so instead we make a JSON (or whatever) description of each
package, and ship that with the package. Then, we interpret that
description as a Nix expression, and do Nix things as usual. Except that
this doesn't work, because now the JSON description is a new package
manager format! We didn't want that.

** So it seems like packages should ship with a Nix expression.

* Packages should be easy to cargo-cult. This might sound weird, but my
experience in other ecosystems (especially Python and Perl) has taught me
that most package descriptions are cargo-culted from other similar
packages. We should have a very custom Nix derivation-producing function
which turns a minimal Nix expression into a full Monte package
description.

So with that in mind, here's where we currently are. We have a runtime and
some packages. There's a terrible terrible Nix function that generates
derivations (
https://github.com/monte-language/typhon/blob/master/default.nix#L11-L34
). An example usage is (
https://github.com/monte-language/mt-rational/blob/master/default.nix ).

As you can see, our derivations are not especially good. We don't have a
good way to locate a runtime so that we can call ``montePackage`` easily.
Once our packages start depending on other Monte packages, the problem
will only be worse. We also have this indirect dependency on nixpkgs for
library stuff, which is worse than a direct dependency or no dependency at
all.

We're seeking any advice on how to make this situation better. As far as
we can tell, nobody else has tried to make Nix their first-class preferred
package management solution for their language, so we are blazing trails
here.

Thanks!
~ C.

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

Re: [Nix-dev] Using Nix as the preferred package manager for a new language

[Rok Garbas]

Quoting stewart mackenzie (2016-02-09 18:32:01)
> We're doing almost exactly this at github.com/fractalide/fractalide.
> Fractalide is a Flow-based programming language implemented in Rust
> 
> We're also facing many of the issues you are :-)
> 
> Rust has a slow compilation, so nix's lazy evaluation means (after a
> long initial build of every component) we only compile the needed
> dependency chain after a change thereafter. Secondly we've have a
> component_lookup (which maps a common name such as
> 'maths_boolean_nand' to /nix/store/-maths_boolean_nand) of which
> every single component is dependent, so we have to build everything
> first time round.
> 
> The only way around this I see: is a conservative language extension
> to hopefully make fbp expressive enough to be able directory walks. ie
> similar to ./. in nix.
> Then...
> The path I'd like to go is that of guix and implement our own nix in
> fbp (bootstrapping with nix) thus we can have a coordination layer
> over rust flow based programming components and components wrapped
> around other non-rust projects such as postgres etc. This would be
> activated as simple as `postgres_instance_1(postgres)`.
> 
> Say for example:
> 
> 'path:(path="${fractalide_docs}")' -> www_dir server(web_server)
> 'domain_port:(domainPort="localhost:8080")' -> domain_port server()
> 
> Normally the above wouldn't be committed into the fractalide repo but
> having a "fractalnix" means ${fractalide_docs} could be evaluated. I'm
> unsure of the details as yet.
> 
> Anyway keen to see this conversation take off!
> 

You could also create a wrapper around nix-build/nix-shell and generate part of
the derivation and feed it to standard buildFlowPackage function, right? Also
instead of generating you could also define a json format or any other format
but then you would have to implement a parser in nix yourself, but it is still
possible.


--
Rok Garbas - http://www.garbas.si


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

Re: [Nix-dev] Using Nix as the preferred package manager for a new language

[Domen Kožar]

There are so many details to distributing software. Let me quickly take a
try to dump my thoughts.

Have a static metadata file that is well defined (has a specification with
a version number of the format).
If you pick JSON, be aware it doesn't allow comments by specification. If
you add comments, most JSON parsers will break.

Having a static metadata file is important, as others might want to parse
it - like anyone trying to figure something out about a package. You could
also define a Nix expression that
can be converted to a JSON and that leaves you the possibility of comments.
But *make sure* the json is generated when the package is "distributed".

Another thing to be careful is to think about dependencies as a DAG. No
circular dependencies. Again, if you take Nix that's already handled.

If you're going to use Nix, be sure to understand how Haskell works. It's
far most sophisticated. A good overview is at
https://www.youtube.com/watch?v=TDnZsBxqeBM=PL_IxoDz1Nq2Y7mIxMZ28mVtjRbbnlVdmy=4

The big downside of using Nix is that people have to use it. If it's not
going to be dead simple, you'll hear swear words :) And that against brings
back to my point one - have a good specification of packaging metadata.
If you are willing to help us improve that barrier, that's amazing since
we're be all better of.

Domen

On Tue, Feb 9, 2016 at 4:40 PM,  wrote:

> Hi! I've tried to start this discussion a couple times on IRC, but it
> hasn't really gotten attention, so:
>
> I'm one of the developers of Monte, a new programming language. We don't
> want to write a package manager, because package managers are hard. (Also
> we've been watching npm happen for the past few years.) So we plan to use
> Nix. However, we've got some requirements for our package layout, and we
> haven't seen anybody else do all of the things we want at once. Here's
> what we're thinking:
>
> * Monte packages shouldn't live in nixpkgs. We use standalone Nix
> expressions to build stuff like our runtime, and it makes development very
> speedy since we do not have to round-trip our Nix changes through nixpkgs.
> We also want to keep Nix expressions for packages close to the packages
> themselves (see next point.) Perhaps when our ecosystem has developed
> more, we can revisit this.
>
> * Monte packages should bundle their own Nix expressions. Our reasoning is:
>
> ** Suppose that we have some "mtpkgs" tree, which is like nixpkgs but only
> contains a Nix expression for building some or all of the Monte runtime
> and packages. However, now we've decoupled the description of the packages
> from the packages themselves, which makes maintaining the package harder,
> since changes to the package require a corresponding change to mtpkgs. We
> didn't gain anything over just using nixpkgs!
>
> ** Okay, so instead we make a JSON (or whatever) description of each
> package, and ship that with the package. Then, we interpret that
> description as a Nix expression, and do Nix things as usual. Except that
> this doesn't work, because now the JSON description is a new package
> manager format! We didn't want that.
>
> ** So it seems like packages should ship with a Nix expression.
>
> * Packages should be easy to cargo-cult. This might sound weird, but my
> experience in other ecosystems (especially Python and Perl) has taught me
> that most package descriptions are cargo-culted from other similar
> packages. We should have a very custom Nix derivation-producing function
> which turns a minimal Nix expression into a full Monte package
> description.
>
> So with that in mind, here's where we currently are. We have a runtime and
> some packages. There's a terrible terrible Nix function that generates
> derivations (
> https://github.com/monte-language/typhon/blob/master/default.nix#L11-L34
> ). An example usage is (
> https://github.com/monte-language/mt-rational/blob/master/default.nix ).
>
> As you can see, our derivations are not especially good. We don't have a
> good way to locate a runtime so that we can call ``montePackage`` easily.
> Once our packages start depending on other Monte packages, the problem
> will only be worse. We also have this indirect dependency on nixpkgs for
> library stuff, which is worse than a direct dependency or no dependency at
> all.
>
> We're seeking any advice on how to make this situation better. As far as
> we can tell, nobody else has tried to make Nix their first-class preferred
> package management solution for their language, so we are blazing trails
> here.
>
> Thanks!
> ~ C.
>
> ___
> 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] Using Nix as the preferred package manager for a new language

[Rok Garbas]

Hi,

While I don't work on any new language I do work with large sets of packages
which I have to keep stable and at the same time develop them.

What bothers me with in most programming languages and their package managers
is that there is no known-good-set of working together packages. Stackage (from
haskell world) is a nice example how I would envision if I would have a chance
to start from scratch. This is similar to your idea of `mtpkgs`.

I'd extend `mtpkgs` to a fixed revision of `nixpkgs`. `mtpkgs` would be
a collection of url+sha256, pointing to the default.nix in that tarball. This
way you get best of both worlds: stability and extensability via local
default.nix.

A release to `mtpkgs` would be a PR with new url+sha256 which you can test if
it builds before merging. If you structure `mtpkgs` you shouldn't see have any
merge conflicts. Ofcourse this could be done nicely with some tools build
around github/nix.

With introductions of `buildins.fetchTarball` this is made very easy to do.

What most package managers fail to deliver is the promise of letting you know
(as a author of a package) that your package is not working for everybody.
I think this is the most important things that some try to hide it and put it
on the shoulders of developers (eg. you should test that your package works
with everything), which is insane requirement. I think with Nix you can achieve
this while not hurting UX and ease of usage.

My 2 cents.


Quoting c...@corbinsimpson.com (2016-02-09 17:40:29)
> Hi! I've tried to start this discussion a couple times on IRC, but it
> hasn't really gotten attention, so:
> 
> I'm one of the developers of Monte, a new programming language. We don't
> want to write a package manager, because package managers are hard. (Also
> we've been watching npm happen for the past few years.) So we plan to use
> Nix. However, we've got some requirements for our package layout, and we
> haven't seen anybody else do all of the things we want at once. Here's
> what we're thinking:
> 
> * Monte packages shouldn't live in nixpkgs. We use standalone Nix
> expressions to build stuff like our runtime, and it makes development very
> speedy since we do not have to round-trip our Nix changes through nixpkgs.
> We also want to keep Nix expressions for packages close to the packages
> themselves (see next point.) Perhaps when our ecosystem has developed
> more, we can revisit this.
> 
> * Monte packages should bundle their own Nix expressions. Our reasoning is:
> 
> ** Suppose that we have some "mtpkgs" tree, which is like nixpkgs but only
> contains a Nix expression for building some or all of the Monte runtime
> and packages. However, now we've decoupled the description of the packages
> from the packages themselves, which makes maintaining the package harder,
> since changes to the package require a corresponding change to mtpkgs. We
> didn't gain anything over just using nixpkgs!
> 
> ** Okay, so instead we make a JSON (or whatever) description of each
> package, and ship that with the package. Then, we interpret that
> description as a Nix expression, and do Nix things as usual. Except that
> this doesn't work, because now the JSON description is a new package
> manager format! We didn't want that.
> 
> ** So it seems like packages should ship with a Nix expression.
> 
> * Packages should be easy to cargo-cult. This might sound weird, but my
> experience in other ecosystems (especially Python and Perl) has taught me
> that most package descriptions are cargo-culted from other similar
> packages. We should have a very custom Nix derivation-producing function
> which turns a minimal Nix expression into a full Monte package
> description.
> 
> So with that in mind, here's where we currently are. We have a runtime and
> some packages. There's a terrible terrible Nix function that generates
> derivations (
> https://github.com/monte-language/typhon/blob/master/default.nix#L11-L34
> ). An example usage is (
> https://github.com/monte-language/mt-rational/blob/master/default.nix ).
> 
> As you can see, our derivations are not especially good. We don't have a
> good way to locate a runtime so that we can call ``montePackage`` easily.
> Once our packages start depending on other Monte packages, the problem
> will only be worse. We also have this indirect dependency on nixpkgs for
> library stuff, which is worse than a direct dependency or no dependency at
> all.
> 
> We're seeking any advice on how to make this situation better. As far as
> we can tell, nobody else has tried to make Nix their first-class preferred
> package management solution for their language, so we are blazing trails
> here.
> 
> Thanks!
> ~ C.
> 
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev


--
Rok Garbas - http://www.garbas.si


signature.asc
Description: signature
___
nix-dev mailing