[Nix-dev] Python bindings to librsvg or gnome-desktop
Hello,
I am trying to create a Nix expression for solfege [1] and got it
building fine using the Nix expression available as Gist [2].
However, running the application fails with the following error,
cryptographic hashes replaced by dots.
Traceback (most recent call last):
File /nix/store/...-solfege-3.20.4/share/solfege/solfege/startup.py, line
159, in start_gui
solfege.win = w = MainWin(options, datadir)
File /nix/store/...-solfege-3.20.4/share/solfege/solfege/mainwin.py, line
119, in __init__
stock.SolfegeIconFactory(self, datadir)
File /nix/store/...-solfege-3.20.4/share/solfege/solfege/stock.py, line
71, in __init__
self.add_icons(d)
File /nix/store/...-solfege-3.20.4/share/solfege/solfege/stock.py, line
33, in add_icons
iconset =
gtk.IconSet(gtk.gdk.pixbuf_new_from_file(os.path.join(self.datadir,
filename)))
glib.GError: Couldn't recognize the image file format for file
'/nix/store/..-solfege-3.20.4/share/solfege/graphics/solfege.svg'
This issue has been addressed [3] and appears to be an issue not
caused by solfege but by a missing python dependency [4]. It is solved
by making solfege depend on python-rsvg. However, I cannot find this
package in Nixpkgs. Further research revealed that this binding is now
part of the Python bindings to Gnome [5]. As observable in the current
NIx expression I added the dependency gnome_python hoping this would
solve the problem. However, it does not.
Is it correct that gnome_python are the Python bindings to Gnome
Desktop which should contain pyrsvg? If not, is pyrsvg already
packaged? If not, where can I find the sources of python-gnome-desktop
and where would be a good place to place a Nix expression for this?
Or could it be the case that this functionality should be supplied by
pygtk, but this (optional?) feature is disabled due to missing
dependencies?
Since I am already at it, why are some packages referenced by
pythonPackages.{package} and some solely by {package}? For instance,
the python sqlite3 module appears to be pythonPackages.sqlite3 whereas
python bindings to GTK+ are not available as pythonPackages.gtk or
pythonPackages.pygtk but as pygtk.
When creating a Nix expression that depends on python packages, Is it
more desirable to depend on pythonPackages or the inherit the
pythonPackages.* subpackages as necessary?
Regards,
Alexander Foremny
[1] http://solfege.org
[2] https://gist.github.com/2953069
[3] http://code.google.com/p/solfege/issues/detail?id=255
[4] https://bugs.launchpad.net/ubuntu/+source/solfege/+bug/1004485
[5] http://www.rittau.org/blog/20060418-00
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Python bindings to librsvg or gnome-desktop
gnome support is only rudimentary (enough to make some packages work). Look at configure output of pygtk etc (force a rebuild [1] and do nix-store -l $out-path) If you start working on python stuff please be aware that I feel that the current PYTHONPATH implementation in nixpkgs is not enough. Some packages such as virtinst would require heavy patching - others do not. For that reason I've tried an alternative implementation introducing NIX_PYTHON_SITES: https://github.com/MarcWeber/nixpkgs/blob/experimental/nix-python-sites/.topmsg But this might be totally unrelated to your issues. When creating a Nix expression that depends on python packages, Is it more desirable to depend on pythonPackages or the inherit the pythonPackages.* subpackages as necessary? I don't know. I personally tried packaging everything found on PyPi - but that index is not that well maintained - a lot of libraries are missing. So for now I expect a lot of manual work to be done on python packages. The common case seems to be that packages which have lot's of C dependencies (such as gtk) are more likely to be put into top-level files. Whether this is desired behaviour - I don't know exactly. If you publish your patches I may have a look at it. That's my personal view on it. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Python bindings to librsvg or gnome-desktop
Thanks for your quick response. Could you please give me the reference for [1]? I don't know how I can force building a package. 2012/6/19 Marc Weber marco-owe...@gmx.de: gnome support is only rudimentary (enough to make some packages work). Look at configure output of pygtk etc (force a rebuild [1] and do nix-store -l $out-path) If you start working on python stuff please be aware that I feel that the current PYTHONPATH implementation in nixpkgs is not enough. Some packages such as virtinst would require heavy patching - others do not. For that reason I've tried an alternative implementation introducing NIX_PYTHON_SITES: https://github.com/MarcWeber/nixpkgs/blob/experimental/nix-python-sites/.topmsg But this might be totally unrelated to your issues. When creating a Nix expression that depends on python packages, Is it more desirable to depend on pythonPackages or the inherit the pythonPackages.* subpackages as necessary? I don't know. I personally tried packaging everything found on PyPi - but that index is not that well maintained - a lot of libraries are missing. So for now I expect a lot of manual work to be done on python packages. The common case seems to be that packages which have lot's of C dependencies (such as gtk) are more likely to be put into top-level files. Whether this is desired behaviour - I don't know exactly. If you publish your patches I may have a look at it. That's my personal view on it. Marc Weber ___ 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] Python bindings to librsvg or gnome-desktop
Excerpts from Alexander Foremny's message of Tue Jun 19 11:25:55 +0200 2012: Thanks for your quick response. Could you please give me the reference for [1]? I don't know how I can force building a package. Just open the derivation and add FOO=BAR; or such passing an additional env var causing a rebuild. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS channel
Hi Eelco,
Very interesting information regarding the channels. Can you give some
additional advice on how this relates to existing /etc/nixos/* checkouts?
* If I specify the channel and the nixos-rebuild you summarized below,
will it use the channel or my checkouts or both (and if the latter, which
has priority)?
* I currently have local packages in ~/.nix-defexpr. Specifically I have:
~/.nix-defexpr/localnix:
{}:
let
stdpkgs = import
/etc/nixos/nixpkgs/pkgs/top-level/all-packages.nix{};
mypkgs = builtins.getEnv HOME + /my_nixexprs;
in
import mypkgs { inherit stdpkgs };
I can then populate personal packages in the mypkgs tree and they are
smoothly integrated for nix-env. Is it still possible to do this somehow
with the channel setup?
* As a corollary, is there documentation I could use that would provide
information on how to create a new channel containing mypkgs?
* Can you --add multiple channels?
* Can multiple channels cross-reference packages? Total
cross-referencing or backward-only?
* How are conflicts resolved with multiple channels?
Many Thanks,
-Kevin
On Tue, 15 May 2012 11:11:43 -0700, Eelco Dolstra
eelco.dols...@logicblox.com wrote:
Hi all,
Since a few weeks there is a NixOS channel, which is now the default
mechanism
for keeping NixOS up to date. (A channel is a Nix mechanism for
distributing a
consistent set of Nix expressions and binaries.) A quick summary on how
to use it:
$ nix-channel --add
http://nixos.org/releases/nixos/channels/nixos-unstable
$ nix-channel --update
$ nixos-rebuild switch
The NixOS channel contains a copy of Nixpkgs (but only the binaries for
i686-linux and x86_64-linux), so after nix-channel --update you can
install
packages via nix-env:
$ nix-env -i thunderbird
or, if you prefer the -A option:
$ nix-env -iA nixos.pkgs.thunderbird
The advantages of using a channel over the previous way (doing svn up
/etc/nixos/* a.k.a. nixos-checkout) are:
- Correctness: The channel is only updated to a new revision of
NixOS/Nixpkgs if
it passes certain tests - specifically, if all jobs in the
nixos:tested view
succeed (http://hydra.nixos.org/view/nixos/tested). So you have a
reasonable
certainty that the new version will actually work. By contrast, if you
update
to the latest revision using nixos-checkout, it's quite possible that
somebody
just committed something that broke the entire system.
- Efficiency: The channel is only updated after all Hydra builds in that
revision have finished, *and* all binaries have been mirrored. (Binary
patches
are generated asynchronously, however, since they can take much longer to
produce.) So you don't have to worry about somebody just having
committed
something that causes a huge recompilation.
This makes keeping NixOS up to date a rather more pleasant activity,
IMHO.
Some things to note:
- The downloaded channel sources are stored in
/nix/var/nix/profiles/per-user/root/channels/nixos (which is actually in
the Nix
store). The $NIX_PATH environment variable contains this directory, so
nixos
and nixpkgs in Nix expressions resolve there unless overriden through
$NIX_PATH or the -I flag.
- In principle, you can do rollbacks on the channels profile (nix-env -p
/nix/var/nix/profiles/per-user/root/channels --rollback) if you don't
like the
result of a nix-channel --update. However, this doesn't roll back the
corresponding binaries manifest in /nix/var/nix/manifest so its utility
is
limited [1].
- The NixOS installation CD no longer contains or installs
/etc/nixos/{nixos,nixpkgs} but instead uses the NixOS channel. You can
of
course run nixos-checkout if you want a working tree for development.
(In
other news, nixos-checkout now accepts a argument to specify the
desired
location of the working trees, e.g. nixos-checkout /home/eelco/Dev.
The
default location /etc/nixos may eventually go away since it's a weird
location
for keeping large source trees.)
- To use a development tree in nixos-rebuild, just use the -I flag, e.g.
nixos-rebuild switch -I /home/eelco/Dev.
- The nixpkgs_sys link in ~/.nix-defexpr is no longer created.
Instead you
can use nixos.pkgs in nix-env -iA calls, as shown above.
nixos.pkgs is
the Nixpkgs in the NixOS channel, so it's guaranteed to have binaries
available.
- The command nixos-version prints out the NixOS version you're
currently
running, e.g. 0.1pre34067-34075. The version string include the NixOS
and
Nixpkgs revisions, respectively. If you install from SVN it just prints
0.1pre-svn.
- Old versions can be installed from http://nixos.org/releases/nixos/.
These
are periodically deleted because they take up a lot of space. (Note
that the
nixos-unstable channel is really just a link to the latest NixOS
release.)
[1] In the future
Re: [Nix-dev] NixOS channel
2012/6/19 Kevin Quick qu...@sparq.org
Very interesting information regarding the channels. Can you give some
additional advice on how this relates to existing /etc/nixos/* checkouts?
As I understand it, all utilities will use channels by default but for
backward compatibility, in case there are no channel subscriptions, there
are pointers to /etc/nixos/* in $NIX_PATH so everything will fall back to
using those old locations.
* I currently have local packages in ~/.nix-defexpr. Specifically I have:
~/.nix-defexpr/localnix:
{}:
let
stdpkgs = import
/etc/nixos/nixpkgs/pkgs/top-level/all-packages.nix{};
mypkgs = builtins.getEnv HOME + /my_nixexprs;
in
import mypkgs { inherit stdpkgs };
I can then populate personal packages in the mypkgs tree and they are
smoothly integrated for nix-env. Is it still possible to do this somehow
with the channel setup?
See [this recent discussion][1].
By the way, I guess, you'd rather be using ``packageOverrides`` in
/.nixpkgs/config.nix instead of your localnix expression.
* Can you --add multiple channels?
Sure.
* Can multiple channels cross-reference packages? Total
cross-referencing or backward-only?
Doesn't seem to be a good idea anyway…
* How are conflicts resolved with multiple channels?
If you use package names, then the best match will be determined as always,
I guess. You should use -A option to distinguish different sources.
[1]: http://thread.gmane.org/gmane.linux.distributions.nixos/8834
--
Кирилл Елагин
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Python bindings to librsvg or gnome-desktop
On Tue, 19 Jun 2012 11:12:31 +0200, Marc Weber marco-owe...@gmx.de wrote: gnome support is only rudimentary (enough to make some packages work). Look at configure output of pygtk etc (force a rebuild [1] and do nix-store -l $out-path) If you start working on python stuff please be aware that I feel that the current PYTHONPATH implementation in nixpkgs is not enough. Some packages such as virtinst would require heavy patching - others do not. For that reason I've tried an alternative implementation introducing NIX_PYTHON_SITES: https://github.com/MarcWeber/nixpkgs/blob/experimental/nix-python-sites/.topmsg And there is: https://github.com/chaoflow/nixpkgs Which works very similar, except: - might not cover all use cases NIX_PYTHON_SITES does (needs to be evaluated) - uses PYTHONPATH only - leaves the python site.py as is, but uses a customized site.py during installs and allows the user to install this customized site.py to make python packages see all other python packages (of the same python version) within a profile. But this might be totally unrelated to your issues. When creating a Nix expression that depends on python packages, Is it more desirable to depend on pythonPackages or the inherit the pythonPackages.* subpackages as necessary? I don't know. I personally tried packaging everything found on PyPi - but that index is not that well maintained - a lot of libraries are missing. So for now I expect a lot of manual work to be done on python packages. The common case seems to be that packages which have lot's of C dependencies (such as gtk) are more likely to be put into top-level files. Whether this is desired behaviour - I don't know exactly. I think all python packages should be available via pythonXYPackages. In addition some python programs, like offlineimap, could be available top-level, using the default python version (currently 2.7). If you publish your patches I may have a look at it. +1 regards florian -- Florian Friesdorf f...@chaoflow.net GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpYBNGl8uDPl.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
