@jbaum98 Why enableParallelBuilding = true; in all the packages you've added?

Thanks for your thorough feedback and sorry for what appears to have been a pretty sloppy PR.

@jbaum98 Why enableParallelBuilding = true; in all the packages you've added?

This could be entirely misguided, but I always set enableParallelBuilding = true; because I think 99% you want to be using all your cores, in part based on #5489.

Although for pylev getting the GitHub source worked so we could run tests because it uses setup.py, for clikit I'm running into a chicken-egg problem because it wants to use poetry as its build system to build from pyproject.toml. Thoughts?

My instinct is we bootstrap just by not using tests, and then somehow use that that poetry to rebuild its dependencies with tests, but I'm not sure how to do that.

I think we'd have to add a build-python-package-poetry at https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/interpreters/python if we wanted to build these project that use poetry. And obviously we'd have to merge this pr first before that.

However it is confusing that they'd distribute a setup.py in the tarball but not on their github repos.

However it is confusing that they'd distribute a setup.py in the tarball but not on their github repos.

I'm guessing poetry produces the setup.py automatically when distributing because poetry isn't ubiquitous.

Okay, I think I've fixed anything that isn't the poetry package test situation. Should I squash these commits one per package or one all together and we can land this PR, and then figure out how to bootstrap poetry?

Okay, I think I've fixed anything that isn't the poetry package test situation. Should I squash these commits one per package or one all together and we can land this PR, and then figure out how to bootstrap poetry?

I'll give your new commits a quick look to see if they're resolved properly. And yes we'd like a commit for each package.

As for the poetry test situation, I agree with that flow.

Remember to add doCheck = false; for the ones that we still can't get tests for.
Also add a comment above with why.

@jbaum98 Great, squash at will. Then I will begin some testing locally.

As for being able to build poetry based python packages, I think we can do something similar to what's done for flit.

I'm happy to be the maintainer for these packages if that makes sense, but I'll need to add myself to the maintainers list.

#53599 (comment)
we don't have Python 3.4 on master anymore, so this shouldn't be needed.

My thought was that this is the constraint in the build file and it doesn't hurt to leave it here as documentation/just in case.

I agree with @jbaum98 even if it's not needed. I tend to try and make the derivation respect the things specified by upstream as close as possible.

Unless they want crazy nonsense that is, then maybe patch it all away 😄

I'm happy to be the maintainer for these packages if that makes sense, but I'll need to add myself to the maintainers list.

That shouldn't be a problem I guess. Just add yourself in the first commit in this branch (this is what most new contributors do).

@jbaum98 Thanks for your contribution 🎆

Fyi I've repackaged poetry with poetry2nix in https://github.com/adisbladis/poetry2nix/tree/master/pkgs/poetry (1.0.0b5).

This fixes a bunch of issues that this package currently has:

• It doesn't propagate PYTHONPATH
  This ensures that things building with poetry as a PEP518(pyproject.toml) build-system will not get a mix of dependencies from your pyproject.toml and nixpkgs poetry.
  It does this by using a similar "vendoring" approach as the official poetry installer does.
• build-system is a first class supported thing
  Poetry is injected into the build if it's defined as a build-system
• It does not require overriding any modules from python-packages.nix
  A unique coherent package set is created for every leaf package, thus avoiding conflicts between dependencies.
• It's dynamic and builds from pyproject.toml/poetry.lock.
  This makes packaging things much easier, a typical Poetry project packaged looks something like:

poetry2nix.mkPoetryPackage {
  inherit python;
  pyproject = ./pyproject.toml;
  poetryLock = ./poetry.lock;
  src = fetchFromGitHub {
    owner = "sdispater";
    repo = "poetry";
    rev = "1.0.0b5";
    sha256 = "1l7vd233p9g8sss5cxl6rm6qyf55ahbb9sw7zm3sd5xchcsiyday";
  };
}

I intend to get this into nixpkgs as soon as Poetry releases a 1.0.