[Nix-dev] python application vs python environment

[Marc Weber]

Excerpts from Florian Friesdorf's message of Fri Sep 23 20:46:12 +0200 2011:
> By wrapping the python interpreter (see pythonhomeWrapper) and setting
> PYTHONHOME to the profile, this can be prevented and site-packages are
> correctly available.
Yes, but it won't work if you want to make configure scripts find
dependencies unless you start building up temporary PYTHONHOME's for
each build.

The better solution NIX_PYTHON_SITES patch has been implemented by me
and some packages such as pygtk has been patched properly (not for 3.0
though). Its like PYTHONHOME but supports multiple paths which requires
some packages to be patched because they want to install into that one
HOME.

Eventually you should consider having a look at my work. Its not
complete, But I'm pretty sure that it has some pretty nice ideas.

For ruby I start building up environments for individual projects:

    rubyCollection =
      let ro = (pkgs.overlay "ruby");
      in ro.rubyEnv19 {
          names = [ "rake" "rails" "bundler" "escape"
            # comomnly used databases
            # "sqlite3-ruby"
            "rspec"

            "sinatra" "haml" "hpricot" /* html2ruby */
            "mechanize" "nokogiri"
            "sass"

            "selenium-webdriver"

            "psych"
            "serviceproxy"
            "wasabi"
            "savon" # SOAP
            # "xapian"

            # "debug_log"
            # "debuggie"
            # "ruby-debug-base19"
            # "rudebug"

            # ruby debugger vim plugin:
            # "socket" 
            # "ruby-debug19" 
            # "linecache19"
            # "columnize" "linecache19" "ruby-debug-base19" "ruby-debug-ide19"
          ];
         };

That's all you have to do to get a ruby-env-ruby which you can use to run any
app even your shell (which requires the multiple shell support patch)

ruby-env-sup sup # define env so that sup ruby mail client runs

ruby-env-ruby zsh # run zsh and make irb and ruby find the defined libraries
along with the depndencies.

The system is strong enough to not allow two versions of the same libraries to
be put into the same env. It also resolves dependencies automatically.
You can add version constraints eg force "savon == 3.2".

Needless to say that those envs also generate tag files for you automatically.

> Instead we need a python that stops resolving symlinks once it reached
> its home profile (not continuing into its derivation).
> 
> A solution would be, not to link python and pythonX.Y from the
> derivation, but instead to create two wrappers that set the PYTHONHOME
> and call then the python in the derivation.
I have to think about this. I won't have time within the next 8 days or so.

> How can I influence how a derivation is merged into another derivation?
Not sure what you're referring to here.

Regards
Marc Weber