@risicle Thanks a lot for picking this up!

@ofborg build python37Packages.cassandra-driver python38Packages.cassandra-driver

getting a failure from geomet, there is a 0.2.1.post on pypi

  Processing ./geomet-0.2.1-py3-none-any.whl
  ERROR: Package 'geomet' requires a different Python: 3.8.6 not in '>2.6, !=3.3.*, <3.8'
cannot build derivation '/nix/store/wi330bni0g0ybm6pp0fa8ngvwd2fy78p-python3.8-cassandra-driver-3.24.0.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/zbppwrvd6ynb66c8dx8vm2kq9d6j0wnx-env.drv': 2 dependencies couldn't be built
[8 built (1 failed), 7 copied (1.9 MiB), 0.4 MiB DL]
error: build of '/nix/store/zbppwrvd6ynb66c8dx8vm2kq9d6j0wnx-env.drv' failed
https://github.com/NixOS/nixpkgs/pull/100989
2 packages failed to build:
python38Packages.cassandra-driver python38Packages.geomet

5 packages built:
python27Packages.geomet python37Packages.cassandra-driver python37Packages.geomet python37Packages.gremlinpython python38Packages.gremlinpython

Hmmyes. There's no tagged release for the 3.8 fix, but I might just pull it in as a patch...

@ofborg build python38Packages.cassandra-driver

@risicle please solve the merge conflict.

Ping @risicle. Do you want to continue on this?

Sure, I just have a few things on my TODO list - currently working on a second attempt of #93083

Updated, retested macos 10.14, non-nixos linux.

@ofborg build python37Packages.cassandra-driver python38Packages.cassandra-driver python39Packages.cassandra-driver

I don't get it - why didn't you request these changes when you made your first pass? More to the point, how many times do we have to iterate this process until I've satisfied every last one of your personal style preferences? From the fact that I've had this on my TODO list since October, you should see I don't have a lot of time for this stuff, but you'd prefer to keep it bouncing.

I don't get it - why didn't you request these changes when you made your first pass? More to the point, how many times do we have to iterate this process until I've satisfied every last one of your personal style preferences?

I think we should be good to go after this. I am human and I can always miss something and notice it later. I think that's better than not noticing it at all. Also in the last two months I learned a lot of things and nixpkgs evolved. For example stdenv.lib got deprecated and is no longer allowed to get re-introduced.

From the fact that I've had this on my TODO list since October, you should see I don't have a lot of time for this stuff, but you'd prefer to keep it bouncing.

I can't know if you don't have enough time ,you forgot it or just missed the notification. I let it bounce once to you which I think is reasonable to do especially after two months.

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.

Result of nixpkgs-review pr 100989 run on x86_64-linux 1

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.

Result of nixpkgs-review pr 100989 run on x86_64-darwin 1

My point is that being overly picky about stylistic things really just puts off contributors. If something straightforward (like perhaps deciding to upstream one of your team's fixes after work for the good of the community) is going to become a multiple week saga bouncing back and forth talking about newlines and semi-colons, people just aren't going to bother because they have other things to do that feel a lot more productive.

My point is that being overly picky about stylistic things really just puts off contributors. If something straightforward (like perhaps deciding to upstream one of your team's fixes after work for the good of the community) is going to become a multiple week saga bouncing back and forth talking about newlines and semi-colons, people just aren't going to bother because they have other things to do that feel a lot more productive.

I agree with that. Getting a PR into nixpkgs is so much work already, even for smaller contributions. Formatting issues should be addressed by an automatic formatter. They shouldn't cost our precious human's time.

My point is that being overly picky about stylistic things really just puts off contributors.

I am not overly picky. Most of the requests are to have a somewhat uniform style to make treewide changes in the future way easier by not having to many variants of essentially the same thing.

I did not order your inputs or sort your phases. Run nixpkgs-hammer on your package and you should see what overly picky looks like.

Getting a PR into nixpkgs is so much work already

It isn't if you follow the contributing guide. Take a look at fabaff PRs since December and a lot of them got merged without any review comments or only very small changes.

Formatting issues should be addressed by an automatic formatter.

There is no formatter that is one stop and does everything. nixpkgs-hammering and nix-fmt should be a good option but they do not cover everything. I am not familiar with programming formatters so I can't improve the situation in a meaningful amount of time.

It isn't if you follow the contributing guide.

@SuperSandro2000 What exactly is the contributing guide? https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md is the only thing I know in that direction, and it doesn't give me enough information to submit PRs that can just be merged as-is. I'd like to learn more.

There is also https://github.com/NixOS/nixpkgs/tree/master/doc/contributing and the language specific doc.

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.

Result of nixpkgs-review pr 100989 run on x86_64-linux 1