[Nix-dev] Several updates to rather important Python packages

Hi Nixers, For some time now I've been submitting new Python packages as well as updates. Occasionally, an update arrives with a very large impact, e.g. the currently available numpy update to 1.10.0 (#10255 ). For some of the cases, like this one, I

[Nix-dev] Trouble packaging llvmlite, Python bindings for LLVM

Dear Nixers, In the last couple of weeks I've been packaging a bunch of Python packages, mostly packages that I use for my research. There is one package though (or in fact, two), that I can't seem to build correctly: llvmlite and numba. The first is a Python binding to LLVM, and the other is a

Re: [Nix-dev] Trouble packaging llvmlite, Python bindings for LLVM

c-2.21/lib/libc.so.6(+0x760be)[0x7f502aa660be] > > > On 30 August 2015 at 09:56, Freddy Rietdijk <freddyrietd...@fridh.nl> > wrote: > >> Dear Nixers, >> >> In the last couple of weeks I've been packaging a bunch of Python >> packages, mostly packa

[Nix-dev] Store nixpkgs licenses as JSON instead of .nix

(using Python) raw license information to the licenses we have in nixpkgs. I don't want to depend on the user having Nix available (just the nixpkgs repository) to convert libraries.nix to JSON. That is my argumentation. What do you think? Kind regards, Freddy Rietdijk

[Nix-dev] NixOS: entry in configuration to list packages that should not be gc-ed

Dear Nixers, There are a bunch of packages I would always like to have available in the Nix store, but that I do not want directly in my primary environment. These packages I would like to specify in `/etc/nixos/configuration.nix` so that on a rebuild these are always available without

Re: [Nix-dev] Install Nix on OSX, install nixops -> runs python2.7-pytest tests

The nixpkgs-unstable channel, which includes OSX packages, hasn't updated in 25 days whereas the nixos-unstable channel was updated 4 days ago. http://howoldis.herokuapp.com/ On Tue, Jun 7, 2016 at 2:54 PM, Maarten Hoogendoorn wrote: > Ah, I see ;) Now it makes sense. > >

[Nix-dev] Fwd: Fwd: Wiki is dead

It makes sense not to have multiple formats inside a single document. As Eelco mentioned, it makes it harder to move around fragments, and, as I experienced now by using the `toDocbook` function, you still end up with XML errors. Therefore, instead of having to debug errors related to one format

[Nix-dev] Python setuptools upgrade and possibly failing builds

Hi Nixers, We're upgrading Pythons setuptools to the latest version [1]. In the latest version setuptools changed behavior with regards to how tests are run, and this might affect one or more of your packages. Up till now we had builds passing the test phase even when no tests were run, often

[Nix-dev] Redesign of documentation

Hi Nixers, Since NixCon last year UX and documentation are in the spotlight, and especially since the Wiki has gone to read-only there seems to be even more pressure to come up with a good solution to the documentation challenge. I would like to bring up a discussion on what type of

[Nix-dev] Fwd: Redesign of documentation

do you think this should be? For example an introduction to the Nix language in the User's manual after or before explaining the introduction to the Nix package manager? On Tue, Feb 16, 2016 at 10:50 AM, Christian Kauhaus <k...@flyingcircus.io> wrote: > Am 15.02.2016 um 18:57 schrieb F

[Nix-dev] Fwd: Wiki is dead

I agree with Vladimir that we already have the infrastructure, the Nixpkgs repository. What is needed is a clearer way where to put certain documentation and a lower barrier for contributing. In `Redesign of documentation` I came with a proposal of how to structure the documentation. A wiki has a

Re: [Nix-dev] Fwd: Wiki is dead

free software but maybe it's worth setting up a > google docs spreadsheet for coordinating the migration once we've settled > on a tool? I will contribute. > > ~ > > [1] > https://github.com/WeAreWizards/nixbyexample > > On 20 February 2016 at 12:06, Freddy Rietdijk

[Nix-dev] Separate repository for autogenerated lists of urls and hashes

Hi, Autogenerating lists with urls and hashes has been discussed before [1,2,3], but I like to bring it up again as I'm working on autogenerating a list with urls and hashes for Python's PyPI packages along with other meta data [4]. At this point I chose to only retrieve data for specific

Re: [Nix-dev] Separate repository for autogenerated lists of urls and hashes

Autogenerating packages is one step further. But it would be nice if there was one source where you could get more of such data from. Maybe https://libraries.io/ some day? To come back to the main topic, autogenerated lists in Nixpkgs. I could imagine it would be nice if we would have also, next

Re: [Nix-dev] Upcoming PyPi URL Scheme Change

Thanks for the update. There are indeed some things we can automate. Before, I experimented with using one of the API's to get out as much metadata as possible. We could also use pypi2nix, which can give for more information, but requires downloading all files. Unfortunately, the old site still

Re: [Nix-dev] Ruby Development on Nix

Hi Taeer, For instance, the python model of > python27Packages.package1 > python27Packages.package2 > is very different from the haskell model of > (haskellPackages.ghcWithPackages (h: with h; [ > package1 > package2 > ]) Actually, they're quite similar. For Python we also have

Re: [Nix-dev] multiple versions of the same software? / collisions

A method to have access to all interpreters is to create a derivation that has symbolic links to each of the interpreters and install that one. But as has been said before nix-shell is the recommended method. On Thu, Aug 4, 2016 at 2:13 PM, Rok Garbas wrote: > for the python

[Nix-dev] Changes to Python infrastructure

Hi, Some time ago I opened a PR to use a fixed-point combinator for Python [1]. It works fine and is, aside from documenting the change (especially regarding overriding), ready. However, before documenting and merging I would like to have some feedback on how it will look like. Right now, we

Re: [Nix-dev] Why having releases if you break things in it often

Hi Stefan, Regarding flexget. There were some security issues with an (indirect) dependency, html5lib, and thus html5lib was upgraded. Maybe that broke flexget, I don't know. The main issue is just a lack of maintainers. It's relatively straightforward to add a package to Nixpkgs, but

Re: [Nix-dev] Why having releases if you break things in it often

why list-derivations and boot options in grub dont are the > same would be interesting? Maybe when I run gc or optimise they vanish > from grub? > > Stefan > > > Freddy Rietdijk <freddyrietd...@fridh.nl> writes: > > > Hi Stefan, > > > > Regarding flexget. There w

Re: [Nix-dev] Python 3 as default

> I would also vote for not changing "default" python as it will break stuff. If we can't break stuff we might as well not make any changes at all. There are definitely differences between Python 2 and 3 causing incompatibilities, but incompatibilities also exist between minor versions, so I

Re: [Nix-dev] Fwd: Python 3 as default

hhochleit...@gmail.com> wrote: > And a copy for the list as well + a one person applause for our > friend, reply-all. > > -- Forwarded message -- > From: Herwig Hochleitner <hhochleit...@gmail.com> > Date: 2017-02-24 4:54 GMT+01:00 > Subject: Re: [Nix-dev] Py

Re: [Nix-dev] Python 3 as default

Peter, could you explain how it broke your setup? On Tue, Feb 14, 2017 at 1:14 PM, Peter Simons wrote: > Hi Richard, > > > Out of interest can I ask what the rationale for that decision is? > > > > I'd like to try to persuade you not to symlink python to python3, > >

Re: [Nix-dev] Python 3 as default

he shebang line only for scripts that are source compatible with both Python 2 and 3. Freddy On Tue, Feb 14, 2017 at 10:40 AM, Richard Ipsum <richardip...@fastmail.co.uk > wrote: > On Mon, Feb 13, 2017 at 10:08:07AM +0100, Freddy Rietdijk wrote: > > Hi, > > > >

Re: [Nix-dev] Python 3 as default

14, 2017 at 12:11 PM, Richard Ipsum <richardip...@fastmail.co.uk > wrote: > On Tue, Feb 14, 2017 at 11:29:32AM +0100, Freddy Rietdijk wrote: > > Hi Richard, > > > > Thanks for sharing the PEP. > > > > Actually, we, or at least I, chose to ignore that PEP

Re: [Nix-dev] Python 3 as default

Peter, that issue we can fix by setting the priority for Python 2 higher. That should also be done in `python.buildEnv`. So aside from symlinking, there are I think two other methods. One, fixing all the shebangs ourselves. Two, modify `patchShebangs` to have an exception for Python so it will

Re: [Nix-dev] Python 3 as default

people's expressions. If anyone is willing to contribute their sed-fu to do such mass-replacement then I don't see any reason why not. On Tue, Feb 14, 2017 at 4:22 PM, Eelco Dolstra <eelco.dols...@logicblox.com> wrote: > Hi, > > On 02/13/2017 10:08 AM, Freddy Rietdijk wrote: &

[Nix-dev] Python 3 as default

Hi, As you may be aware the plan is to change to Python 3.5 as default for 17.03. There were a couple of things that had to be done, and I think we're ready now to make the change. Packages that require Python 2 are now pinned to do so. Now, obviously I haven't been able to test all packages

Re: [Nix-dev] Python 3 as default

; On 2017-02-13 10:08, Freddy Rietdijk wrote: > > Hi, > > > > As you may be aware the plan is to change to Python 3.5 as default for > 17.03. There were a couple of things that had to be done, and I think we're > ready now to make the change. Packages that require Python 2 are

Re: [Nix-dev] Explicitly selecting sources for "src" in stdenv.mkDerivation?

> src = [ ./subproject-A/schema.sql ./subproject-A/lib ]; Each of the files you mentioned here will be stored in a separate store path. You could write a simple function that takes a list of derivations and copies the contents of those derivations in a new output. On Thu, Feb 16, 2017 at 1:14

Re: [Nix-dev] Fwd: Python 3 as default

ython.org/dev/peps/pep-0394/#id5 On Mon, Feb 27, 2017 at 4:20 PM, Eelco Dolstra <eelco.dols...@logicblox.com> wrote: > Hi, > > On 02/24/2017 07:54 AM, Freddy Rietdijk wrote: > > >> I'd be happy to help with the process of mass-renaming, if somebody > provided a > &

Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

We could let the mention-bot ignore certain files "fileBlacklist": ["*.md"], // mention-bot will ignore any files that match these file globs On Sat, Sep 3, 2016 at 1:03 PM, Shea Levy wrote: > No, not something automated like that. Though mention-bot seems to work >

[Nix-dev] Multiple stores

Hi, I would like to use Nix for a certain data analysis where I will have several thousand files which are all together about two TB in size. At the moment NixOS is installed on a SSD which is a quarter that size. Would it be possible to install a second store elsewhere, in this case on a slower

Re: [Nix-dev] Multiple stores

gt; On Fri, Aug 26, 2016 at 02:51:02PM +0200, Freddy Rietdijk wrote: > > I would like to use Nix for a certain data analysis where I will have > > several thousand files which are all together about two TB in size. > Do these 2 TB of data really have to be stored in the nix-store? &

Re: [Nix-dev] Remove Python 2.6 and 3.3

at 1:29 PM, Matthias Beyer <m...@beyermatthias.de> wrote: > I have 702 paths in /nix/store which contain the string "python2" > > Can you tell me how to check properly whether I need python2 > support/packages? I'm not so familiar with the python infrastructure. > &

Re: [Nix-dev] Python: a bit fatter interpreter

41 MB while at the same time the amount of headaches will be reduced significantly. On Wed, Oct 26, 2016 at 5:43 PM, Eelco Dolstra <eelco.dols...@logicblox.com> wrote: > Hi, > > On 10/26/2016 04:36 PM, Freddy Rietdijk wrote: > > > Today I merged staging into master, a

[Nix-dev] Python: a bit fatter interpreter

Hi, Today I merged staging into master, and this brings some changes to CPython. Of importance is that the different versions of the interpreter now come with the whole standard library, except for tkinter. This module can be found at pythonPackages.tkinter. Therefore, if you get evaluation

[Nix-dev] Nix with fetchTarball that supports hash

Hi, On July the 26th support was added to `fetchTarball` for a `sha256` attribute [1]. Since that commit, it is also possible to use `fetchTarball` with the hash in restricted mode, thereby making it possible to load e.g. an external repository with urls and hashes. `nixUnstable` currently

Re: [Nix-dev] pypi2nix: generate full PYTHONPATH from requirements?

I am not familiar with the details of pypi2nix, but try and use `python.withPackages` to create an environment where all packages can be found by the interpreter. PYTHONPATH is still used a lot, especially with modules, but we shouldn't be using it. http://nixos.org/nixpkgs/manual/#python On

Re: [Nix-dev] pypi2nix: generate full PYTHONPATH from requirements?

Hlynskyi <abcz2.upr...@gmail.com> wrote: > pypi2nix supports `python.withPackages`. But how should I use the created > "environment" in NixOS service? > > path = [ python-env ]; > > doesn't work > > 2016-11-05 22:59 GMT+02:00 Freddy Rietdijk <fredd

Re: [Nix-dev] buildFHSUserEnv and matlab impure install

I guess the approach here is 1. Make sure you have all the installation files offline in an archive. 2. Prepare file for silent installation https://sysadminblogger.wordpress.com/tag/matlab-offline-installation/ 3. Write a Nix expression that uses `buildFHSUserEnv` and use

[Nix-dev] Python: getting rid of PYTHONPATH in Nixpkgs

Hi, Currently we use PYTHONPATH a lot in Nixpkgs to let applications and the interpreter find Python modules. This typically works fine, but there are problems with this method and so I would like to get rid of it and use only

[Nix-dev] Bot that replies to PR with review points based on files that were touched

Hi, Currently we have the mention-bot that checks which files PR modifies, and then mentions users that have modified those files before or are explicitly watching those files. These contributors can then check the PR and maybe come up with specific questions regarding the PR. I'm looking for a

Re: [Nix-dev] Eval breakage in master

Hi, I am looking into this. The error was already on staging. The problem is line 1390 in all-packages.nix. Something likely gone wrong with a merge. Freddy On Wed, Oct 26, 2016 at 3:00 PM, Bjørn Forsman wrote: > Hi all, > > $ nix-env -f . -qa '*' --meta --xml

Re: [Nix-dev] Eval breakage in master

> error: while querying the derivation named ‘gnome-encfs-manager-1.8.16’: I've marked this package as broken for now. On Wed, Oct 26, 2016 at 3:44 PM, Bjørn Forsman <bjorn.fors...@gmail.com> wrote: > On 26 October 2016 at 15:03, Freddy Rietdijk <freddyrietd...@fridh.nl&g

Re: [Nix-dev] Extra dependencies for Steam games?

If you would move certain libraries out because of whatever reason, then I think we need to introduce a set that defines per game the extra libraries and introduce something like a steam.withGameLibs. On Fri, Dec 9, 2016 at 11:07 AM, Nikolay Amiantov wrote: > commonTargetPkgs is

Re: [Nix-dev] Reproducibility testing in Hydra

That is a very nice improvement, thanks! Is there a command line tool for checking whether a derivation is reproducible? And when requested generate the diffoscoe output. That would be very convenient to have! Regarding pip. I think we need to use the --build flag to explicitly set a build

[Nix-dev] Multiple outputs: is a first output necessary?

Hi, I'm using Nix and now also multiple outputs for my data analysis and simulations. Many scripts generate several files and instead of having them together in the same store path I would prefer to put them in separate store paths. I'm not using any of the common outputs like $out and $bin. The

Re: [Nix-dev] Extra dependencies for Steam games?

Are you on NixOS? If so, did you add hardware.opengl = { driSupport = true; driSupport32Bit = true; }; On Mon, Dec 12, 2016 at 9:28 PM, Mike Cooper wrote: > Thanks for the replies everyone. As for the meta issue, I think that > having a steam package that is compatible with

[Nix-dev] Python package set now uses fixed-point combinator

Hi, This is to inform those of you that override Python package sets. A fixed-point combinator is now used, and examples are included in the documentation. https://github.com/NixOS/nixpkgs/pull/20893 Freddy ___ nix-dev mailing list

Re: [Nix-dev] Channels, LetsEncrypt, and Security fixes from 2016-12-23 01:26 UTC

Those extra failures seem to be transients. At least, the one that I tested. It is also very unlikely that the only change, a Python 2.7 maintenance version bump, would cause those extra failures. Building 16.09 after the Python bump went fast. There is still a large queue

Re: [Nix-dev] Using/packaging Python-modules

Hi Roland, I've fixed the issues you described with https://github.com/NixOS/nixpkgs/commit/e0d1691ba3ceffe51efb0dfde285a3e29b0002fe I couldn't find > - http://nixos.org/nixpkgs/manual/#ssec-python-development >This anchor des not exist; maybe #development-mode is meant. Could you tell me

[Nix-dev] Python 3.6 as default Python 3 interpreter

Hi, Currently the default Python 3 interpreter in Nixpkgs is version 3.5. Version 3.6 was released in December and a first maintenance-release this March. Unless there are good objections I would like to change the default Python 3 interpreter to version 3.6. This will affect a couple of Python

[Nix-dev] IPython in Nixpkgs

Hi, Currently we have IPython 5.3.0 in Unstable and 17.03. Soon IPython 6 will be released which will only support Python 3.x, and that might mean the Notebook will also no longer support a Python 2.x kernel. As maintainer of the package my intention is to just upgrade to this latest version on

Re: [Nix-dev] Inkscape pythonEnv - .sif export - PYTHONPATH wrapping

You wrote the following to me directly: > Can you try regression exporting .sif files? > How to: Export -> select filter sif. > A simple rectangle is enough, the error I get is "lxml" not found. > Have a look at your commit: You left the comment there, but dropped teh > wrapProgram (which

[Nix-dev] wrapProgram: also pass name as NIX_PROGRAM_NAME

Hi, When we create a wrapper we use `exec -a` so that the wrapped program uses the name of the original program. This isn't respected by all programs, e.g. Python ignores this. If I am correct this is the case with all interpreters. How do we handle this with other interpreters? Currently we

Re: [Nix-dev] Python: Provide your own buildPhase and installPhase.

Hi, What are you trying to achieve? You want to package panda3d? The `buildPythonPackage` function builds by default setuptools/distutils Python packages. When passed `format="flit"` it builds from Flit source, and when passed `format="wheel'` it takes the wheel and installs it. The fourth

Re: [Nix-dev] wrapProgram: also pass name as NIX_PROGRAM_NAME

ame. Argv0 > would contain a path to python and argv1 the path to the script. > > Cheers, > z > > On Fri, 19 May 2017, 12:35 Freddy Rietdijk, <freddyrietd...@fridh.nl> > wrote: > >> Hi, >> >> When we create a wrapper we use `exec -a` so that the wr

Re: [Nix-dev] wrapProgram: also pass name as NIX_PROGRAM_NAME

ight get away with pyvenv.cfg). On Mon, May 22, 2017 at 2:36 PM, Eelco Dolstra <eelco.dols...@logicblox.com> wrote: > Hi, > > On 05/19/2017 01:35 PM, Freddy Rietdijk wrote: > > > Therefore, I propose we set an environment variable `NIX_PROGRAM_NAME` > that the > >

Re: [Nix-dev] How to build all of nixpkgs?

If I am correct Hydra first checks which jobs evaluate, and then builds those. It checks using the findJobs function in this file https://github.com/NixOS/hydra/blob/master/src/hydra-eval-jobs/hydra-eval-jobs.cc On May 22, 2017 17:35, "Bjørn Forsman" wrote: > On 22 May

Re: [Nix-dev] Installing manpages

Function for getting all manpages of all pkgs: ``` manpkgs = pkgs: builtins.map (x: lib.getOutput "man" x) pkgs; ``` https://github.com/NixOS/nixpkgs/blob/5989515b9410f3d557e1aba037325a218f4338f5/lib/attrsets.nix#L450 You might want to concatenate the generated list to `pkgs`. On Thu, May 25,

Re: [Nix-dev] Python 3.6 as default Python 3 interpreter

You may have already noticed that 3.6 is now the default 3.x interpreter on Nixpkgs Unstable. Freddy On Thu, Apr 20, 2017 at 11:04 AM, Lancelot SIX <lsix@lancelotsix.com> wrote: > Hi Freddy, > > This sounds good to me ! > > Lancelot. > > On 20/04/2017 10:58, Fr

[Nix-dev] Auto-generated expressions for applications

Hi, At several places in Nixpkgs we use auto-generated data, mostly for the larger package sets like Haskell. Sometimes we also use auto-generated sets for applications that may need different versions than are offered in the main package sets. In the past months several issues/PR's have been

Re: [Nix-dev] Auto-generated expressions for applications

> Current approach seems to be doing the job except notifying people when dependency is updated. What do you base that on? With the generated data sets for applications we have another issue which I didn't mention, and that is the sometimes overly conservative pinning of versions by the

Re: [Nix-dev] [***SPAM***] unzipNLS

Thanks! bd129c2b3e033bd92d5c93cca4d516b021d408e6 On Sun, Jul 9, 2017 at 4:01 AM, Karn Kallio via nix-dev < nix-dev@lists.science.uu.nl> wrote: > > The unzip Nixpkgs expression does not build with the NLS attribute > selected because the patch conditionally applied conflicts with the > earlier