Why are you not exposing infix as a top-level package? That way it could be used independently or by another package that depends on it.

About infix: the author of this package marked it as unmaintained. We use it in pycategories, and would possibly absorb infix into it in case it needed to be altered.

Even if it's stale, it does represent a package on pypi, there may be other packages that may also want to use it.

I'm sure someone else will have stronger opinions on the matter of adding unmaintained packages.

I chose to make it private following a suggestion by @worldofpeace. I do agree that this is useful code, even if unmaintained.

given the nature of the package, makes sense. Although it probably would be more correct for you all to not rely on it all together :) but I understand not wanting to redo the work.

@dmvianna can you rebase instead of merging? It's part of our contribution guidelines https://nixos.org/nixpkgs/manual/#submitting-changes-making-patches

Thanks for the heads up. I can do it going forward, but I cannot fix past history without messing this thread, right?

Thanks for the heads up. I can do it going forward, but I cannot fix past history without messing this thread, right?

True, though I think you mean force pushing would mess up the thread? I've never had a problem in that case (github isn't exactly careful with keeping pr threads readable)

Just so you know, I created an issue upstream to fix the tests in the Pipy package. I prefer we maintain total compatibility with that.

Just so you know, I created an issue upstream to fix the tests in the Pipy package. I prefer we maintain total compatibility with that.

Responding to that issue here

I package the git repository, rather than the Pipy package. That seems wrong, as I would have to make sure I was using in Nix the same commit you used in Pipy, or things would be very confusing.

I don't see a reason why it would be difficult to match the versions, the repo has the tags https://gitlab.com/danielhones/pycategories/-/tags/v1.1.0 which should correspond with what's on PyPI. But actually having the tests in the sdist would be best 👍

@worldofpeace I'm not familiar with gitlab support with nix, IIRC github is supported because there's ways to pull down tarballs, not sure if you can do the same with gitlab.

@dmvianna you're correct that it will "mess up" your commit history, but github handles it's fairly well i would just do something simjlar to:

git rebase HEAD~4 -i # you will be given a list of the commits and how to edit them
# specifically, pick the oldest commit in this case, and then squash the others
# once you save, you will be given another prompt to write the new commit message
git push dmvianna pycategories-1.1.0 --force

@worldofpeace I'm not familiar with gitlab support with nix, IIRC github is supported because there's ways to pull down tarballs, not sure if you can do the same with github.

@risicle Already addressed that there's a fetcher function for this #63503 (comment) fetchFromGitLab.

oh, i wasn't aware this was available, awesome! :)

I am deeply sorry about the reviewer spam I created.

I am deeply sorry about the reviewer spam I created.

Ah don't worry about that, we're pretty much used to it now. It's more of a bug that GitHub has ATM.

Hopefully this is saner. pycategories-1.2.0 includes the tests in the source distribution. Will address the other comments later. @worldofpeace would you be OK with making infix a separate, public package? It is available from pypi after all.

I supplied the rest of the requested changes. As for infix being public I don't think it being published on PyPI any different than being published on GitHub.

Thanks a lot for fixing that upstream @dmvianna ✨

Likewise thanks to our reviewers.