[Nix-dev] Clear all

[Mathijs Kwik]

Stewart Mackenzie <setori88 at gmail.com> writes:

> Mathijs Kwik <mathijs at bluescreen303.nl> wrote:
>
>>You can go a step further and define multiple sub-profiles.
>>For example 1 you typically use during c development.
>>And another for haskell development, and yet another for an
>>experimental python3 environment.
>>Then you can jump between those environments on a per-terminal basis
>>(no interferance, do many different things at once). Like this, you
>>keep the default packageset (and thus "commands" available in your
>>shell path) to a minimum. Look for "myEnvFun" in nixpkgs if you want
>>to try this.
>
> Yes this is exactly where I want to go. I need a C++ and Mozart/oz
> environment, now does one have this default.nix committed to the
> mozart/oz project's repo? 

No you just keep it somewhere in your own repo or somewhere in your
HOME.

> Should one use nix-shell to change to this environment? 

No, the "myEnvFun" environments create their own scripts for this.
If you have an environment called foo, you will have a
~/.nix-profile/dev-envs/foo file containing most stuff that needs to be
set. And a load-env-foo script in your path that sources this and does
some additional things. You can use that or build your own wrapper.
I personally do a little more, like setting the PS1 so I can visually
identify in which environment one terminal is.

> So portablility is ensured by committing the new
> environment to some folder branch in nixpkgs, or just ship
> default.nix? I compile the mozart2 compiler (which is dependent on
> boost) as soon as I try execute the development environment it blowsup
> because it can't see boost deps. So I obviously need a hybrid
> C++/mozart-oz solution.

I think we are getting things mixed up here :)
The stuff I mentioned up to now is for creating custom environments,
which is useful if you need to work with local projects that you have no
desire to turn into a full nix expression, or at least not yet.
Or if you have a bunch of similar projects with similar dependencies.
So a c++ environment with a set of libraries available, a ruby
environment (specific version) with a set of gems, nodejs with a bunch
of npms. 
This resembles a typical environment you would have on other systems and
is very useful for working on local projects (ones you share with
non-nixos users).

nix-shell (and predecessors) is used if you want to work on nix
expressions to get an environment that is very similar to what builders
would use if you install them normally (systemPackages or nix-env,
doesn't matter). Most of the time this is for working on a package that
you maintain for nixpkgs (or want to in the near future), or for "local"
(outside of nixpkgs) projects that you want to deploy to nixos machines,
for example through nixops.
So this is more than just dependencies, but for specifying the full
build instructions for a "package". (full nix expression / derivation).

Of course there is an overlap between these methods.
If you want to use the nix-shell way, it depends on whether your package
is supposed to become part of nixpkgs or if it's just a
personal/proprietary thing.

If you want it in nixpkgs, just put it in your local nixpkgs copy and
submit it when it's ready (through a pull request). If it's personal you
can store the expression anywhere you like (point
nix-build/nix-env/nix-shell to it) or plug it into nixpkgs "externally"
through packageOverrides.

See http://nixos.org/wiki/Howto_develop_software_on_nixos

>
> My dependencies are
> Boost, Tcl, Tk, xlibs, xproto, Java, clang, llvm, gtest, gcc, I also
> have a load of environmental variables. I noticed there is a build.sh
> which allows me to abstract away Mozart's build.
>
> Kind regards
> Stewart
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev