New Release?

[achimgaedke]

Hi there!

I wonder whether it is possible to cut a new release after the major refactor last year.

PyPi shows 0.2.0 from 2019 - https://pypi.org/project/pyprojroot/#history

What can I do to help with this?

[jamesmyatt]

This looks to be the sticking point: #24

[achimgaedke]

I haven't looked into the code/PR in detail, waiting for an another rainy afternoon instead of sudoku or wordle...

Might need some dusting/clean-up, but otherwise github CI trouble?

[achimgaedke]

@jamesmyatt and @chendaniely PTAL: https://github.com/achimgaedke/pyprojroot-release-0.3/commits/achims-edits

This fixes mypy (at least mostly) and uses a "matrix build" to check against multiple python versions.

[jamesmyatt]

@achimgaedke , thank you. You need to raise a pull request so it can be reviewed.

[jamesmyatt]

TBH, I would just remove the strict mypy checking and release a version without it. Rather than hold-up a new version while struggling with the mypy checks. Fixing existing mypy errors belongs on the backlog.

[achimgaedke]

@chendaniely - any idea what you'd like to see or what you'd like to get some help with? (E.g. github CI / packaging)

[achimgaedke]

Just started https://github.com/achimgaedke/pyprojroot2/tree/towards_v2

This project is a fork of Daniel Chen's pyprojroot and based on #28.

The fork moves the project forward to:

• aiming for feature parity with rprojroot version 2
• tested support for python >=3.7
• bring the typing annotations to a useful state (LSP, linters)
• updated packging configuration/toolchain
• (future) increase test coverage
• (future) distribution to pypi and conda as pyprojroot2

[jamesmyatt]

@achimgaedke, I'm not sure that starting a fork is the best option yet. But this project certainly looks abandoned right now.

@chendaniely, Can we add some more maintainers here or transfer the project to someone active, like @achimgaedke, or an organisation to move the project forward, rather than splintering and doubling the effort for everyone?

[jamesmyatt]

@achimgaedke , TBH, if I were you, I'd kick-off the process to take-over the project under PEP 541. IMO, this meets the definitions of Unreachable and Abandoned Project.

[machow]

Hello, to be sure, the criteria for reachability involves the maintainer being reachable by pypi folks.

What are you seeing that tells you the maintainer is not reachable by email to pypi folks? I am all for finding ways to maintain useful packages, but encouraging someone to invoke pep 541 on a package whose maintainer is still active on github feels pretty aggressive.

The user of the Package Index is solely responsible for being reachable by the Package Index maintainers for matters concerning projects that the user owns.

[jamesmyatt]

I don't think that the PyPI maintainers will attempt to contact the owner of a project, unless there is a specific reason to, such as when someone asks them to under PEP 541. Clearly, this is a last resort and not to be invoked lightly, but the burden of "reachable" is very low.

Of course, the ideal solution would be for @chendaniely to respond here, so that we can find a solution that keeps everyone happy, and if he wants to maintain ownership of (and responsibility for) this project, then that will absolutely be respected. But he needs to say so.

While @chendaniely does appear to be active on Github generally, the last activity of any kind I can find in this project is on 30 Mar 2021, which is nearly 2 years ago (22.5 months). Even then, it was a only short period of engagement with the last activity before that being 8 Oct 2019 (40 months), which was the last release. Several people have attempted to contact Daniel publicly and privately via Github, LinkedIn, email, etc, without response. Given that Daniel is otherwise active on Github, I can only conclude, after all this time, that he is choosing to ignore this project. I would love to be proved wrong.

If Daniel doesn't respond, then the only options are either to abandon the pyprojroot name and code to litter the ecosystem forever and develop a fork under a new name (e.g. pyprojroot2), or to use PEP 541 to transfer the pyprojroot name to an active maintainer, and I think the second option is better than the first.

PEP 541 expects owners of active projects to either respond to email contact within 6 weeks OR make a release within the last 12 months OR be otherwise active on the project's home page (i.e. here), and currently we have none of these. So, the next stage, IMO, is effectively for someone who is prepared to take on the burden of maintainership (e.g. @achimgaedke) to use PEP 541 ask the PyPI maintainers to officially attempt to reach the author.

[achimgaedke]

One thing should probably be mentioned:

@chendaniely started this project and brought it to where it is. Thank you, @chendaniely .

We wouldn't have the discussion without him and his work, as this project has a successful history and proved helpful.

Please, @chendaniely - Could you help us making this process easy?

[achimgaedke]

Ok, here're the three options:

• @chendaniely would delegate maintenance and release for pyprojroot on github and pypi
• https://github.com/achimgaedke/pyprojroot2/ would become the new source of the pyprojroot pypi package
• https://github.com/achimgaedke/pyprojroot2/ would become pypi package pyprojroot2

The first bullet point is my (I guess, I'm not alone) preference. The second one would require embarking on the "Continued maintenance of an abandoned project" process.

Reading https://peps.python.org/pep-0541/#continued-maintenance-of-an-abandoned-project - bullet point 4:

the candidate is able to demonstrate why a fork under a different name is not an acceptable workaround; and

All in all, I see the last option as the most likely though not the most desirable.

So what are the reasons against it and for option 2, same package name different fork?

• littering the ecosystem with more slightly random names

[achimgaedke]

Today was (another) rainy day, so I did the research on what needs to happen to get pyprojroot on par with rprojroot.
I rewrote it completely - great to have some unit tests and a collection of user feedback in the issue tracker.

Here's the preliminary result: https://github.com/achimgaedke/pyprojroot2/tree/pyprojroot2-rewrite
For the following steps, I'll move into the user perspective, writing some docs and using the project...