Stewart Mackenzie <setor...@gmail.com> writes: > Mathijs Kwik <math...@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@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
