Future of Pew?

[tjanez]

Firstly, I want to thank you, @berdario, for creating this project. I've been happily using it for years.

In the mean time, I've also became the maintainer of the Fedora package.

Seeing there hasn't been any new commit into master since Apr 16, 2019 and the last pull request that was opened was #214 on Aug 1, 2019, I'm curious if there is any interest in keeping the project alive?

Please, don't take this question as a demand, but rather a sincere inquiry. Thanks!

[pfmoore]

Agreed there's been little change in pew for a while. But there's also not been much activity in the form of issues raised or PRs, so arguably it's merely "stable" rather than "needing to be kept alive". Having said that, though, I'm not the project owner so I can't make a definitive statement here.

(I am a maintainer on the project, and I use it a lot, so I would be willing to help if work is needed - however, I don't have any particular insight into the project "direction", and I would defer to @berdario in the first instance).

[tjanez]

But there's also not been much activity in the form of issues raised or PRs, so arguably it's merely "stable" rather than "needing to be kept alive"

Agreed, Pew has been pretty stable, but some bugs inevitably remain and there is maintenance needed to keep up with the updates to the underlying stack (e.g. newer Python releases, newer virtualenv releases, ...).

(I am a maintainer on the project, and I use it a lot, so I would be willing to help if work is needed)

Cool. Perhaps, a good way to start would be to review the currently open pull requests. #208 seems ready to be merged and #210 and #214 are ready for review (the AppVeyor tests have failed on those two, but that may be unrelated to the changes in the pull requests themselves).

[pfmoore]

I'd already approved #208, so it's waiting for @berdario IMO. I could merge, but there's not much urgency as I can't do a release so it can wait till there's a release. (It only affects the content of the sdist).

I added a ping to the submitter on #210, as the CI failure needs looking at. It may be unrelated, but I can't say for sure.

For #214, what versions we support is a project policy decision, so it's down to @berdario. Personally, I'd drop Python 2 support completely, and be seriously considering desupporting Python 3.5.

[tjanez]

@pfmoore, thanks for taking a look.

For #214, what versions we support is a project policy decision, so it's down to @berdario. Personally, I'd drop Python 2 support completely, and be seriously considering desupporting Python 3.5.

Agreed. I leaned on the conservative side and only removed Python versions that have been clearly out of the picture for a long time.

[pfmoore]

There seem to be some difficulties with the test suite, so #214 and possibly some follow-on work to stabilise things is likely to need to be the first step. Note that #214 has failing tests related to Nix support, and I know nothing about that, so it will need input from @berdario. I don't know how active he is these days, but let's see what his views are and take it from there.

[tjanez]

Note that #214 has failing tests related to Nix support, and I know nothing about that, so it will need input from @berdario. I don't know how active he is these days, but let's see what his views are and take it from there.

Cool, agreed.

[berdario]

First of all, apologies for the lack of an update.

as usual, life happened (moved home 4 times in 3 years, among other things)... and replying to github PRs and issues was definitely on my TODO list

though overdue by 344 days 🤦‍♂️

I was historically pretty bearish on dropping support for Python2 in Pew, since Pew should make it easier to be used also on older distro or environments where the system-level Python is not yet Python3...

But as of a couple of months ago, pip dropped support for Python2: https://pip.pypa.io/en/stable/news/#id1

hence, there's not really any point in us keeping support for it... so that's 👍 from me on dropping it

about Nix travis CI failures... I'd look at them myself, but now is not the best time for me :/

I've historically been pretty liberal in adding collaborators to this repo, but I noticed that tjanez hadn't yet been added... that is now fixed (in fact, this update was triggered by an email sent directly to me... )

Thanks for stepping up. I can also grant you access on pypi to publish updates

[pfmoore]

Glad to hear back from you @berdario! I'd be happy to take a more active role as well - I mainly haven't up to now because my preference was to be somewhat more radical in changing things, and from what I recall when we last interacted, you were significantly more conservative. So in the interests of helping you not be so much of a bottleneck, I'll put together some thoughts on how I'd like to develop things, and if you can indicate where you broadly agree or disagree, I'll be able to focus on things we're both happy with. (I have some spare time this next week, so it's an ideal time for me to do some thinking on this).

[frenzymadness]

By the way, Python 3.10 beta 1 is out so, please, don't forget to add it to the CI and make pew compatible with it.

[pfmoore]

@berdario Sorry, I don't think I ever posted my thoughts. Given @tjanez comment here and the changes to CI in that PR, I'd like to revisit the question of where you see pew going.

Personally, I'd like to do the following:

1. Support Python 3.6+ only, and move to a more aggressive policy of only supporting Python versions that are still supported by the core Python team.
2. Switch to Github Actions for CI.
3. Drop support for nix, as the tests seem to be failing and there's no-one who knows enough about nix to do anything about it.
4. Stop supporting installing Python (the Pythonz integration) and focus on just being a virtual environment manager. Again, it's not obvious to me who is available to support that code if it goes wrong, so not making promises we can't keep seems better than having stuff that could fail at any time and block everything.
5. Move away from the (IMO weird) virtualenvwrapper-inspired command names, to more natural names (see Add a "temp" alias for mktmpenv #163, which would be first on the list for me). We could leave the old names as aliases, at least for a period.
6. Tidy up the codebase, for example actually removing the nix/pythonz code, rather than just meaving it as "unsupported but present for now".

The key thing for me is to get a critical mass of people who have the time and interest to work on pew, and focus on features and things that they are comfortable with, and interested in, supporting.

#214 does the first two of the above changes, and I'd love to merge it¹, but I don't want it to be a one-off thing with no real follow-up. If the reality is that the project is in "maintenance only" mode, then I'd prefer to accept that and move on (with the implication being that we're OK with people² who want a more dynamic project creating a fork/successor).

¹ To merge, someone would need to switch off Appveyor. I don't know if anyone other than the appveyor project owner can do that...
² I may be one of those people, I honestly haven't decided yet whether I want to be lead maintainer/owner of such a project, as opposed to "just" a team member.

[tjanez]

@pfmoore, thanks for this write-up. I agree on all of the points your are suggesting.

I'm also tentatively volunteering to help with a revival/fork/successor. The most pressing thing for me is to remove the bitrot and prevent Pew from being kicked out from Fedora's repos.

[pfmoore]

@tjanez Does keeping pew in Fedora require a release with the fixes you've submitted, or is it sufficient to have the PR merged? I can do a merge, but if you need a release I can't do that so it won't actually be that much help...

Edit: Actually, @berdario mentioned above that he'd given you commit rights, so you can probably do the merge yourself?

[tjanez]

@tjanez Does keeping pew in Fedora require a release with the fixes you've submitted, or is it sufficient to have the PR merged? I can do a merge, but if you need a release I can't do that so it won't actually be that much help...

I think it would be sufficient to merge it for now.

Edit: Actually, @berdario mentioned above that he'd given you commit rights, so you can probably do the merge yourself?

Yeah, he gave me commit rights, so I can do it myself once it is ready.

[sanjayankur31]

@berdario : any chance you'd consider creating a pew org or something and handing over pew maintenance to it to allow a more distributed maintenance of the tool (also add folks to pypi etc. so they can make releases there?)?

I still rely heavily on pew, and while @tjanez has made fixes to keep it going in Fedora (thanks a bunch @tjanez !), there are niggles, bugs, and features here and there that still need work. I'm happy to help with these, but it'll be good to know that the project is setup to allow for longer term development before committing resources to it.

(The alternative to keep this maintained and alive is to fork pew and rename it or whatever to be able to publish on pypi, but I don't think any one here wants to do that unless absolutely necessary)

[tjanez]

I still rely heavily on pew, and while @tjanez has made fixes to keep it going in Fedora (thanks a bunch @tjanez !), there are niggles, bugs, and features here and there that still need work. I'm happy to help with these, but it'll be good to know that the project is setup to allow for longer term development before committing resources to it.

There is new work ahead if we want to support Python 3.12: #233.

(The alternative to keep this maintained and alive is to fork pew and rename it or whatever to be able to publish on pypi, but I don't think any one here wants to do that unless absolutely necessary)

I've been trying to reach out @berdario over email but no success yet.

[sanjayankur31]

Maybe we start adding contributions to a repo fork already (your fork maybe?). That way at least people that are happy to install from GitHub can use it with new features/fixes and it continues to be maintained.

And for this issue, we can time box this---if we don't hear back in maybe 2--3 months, we discuss what the best steps to make our improvements available on pypi are (if we need to rename etc.?).

I'm still hoping we hear from @berdario , but best to have some plan in place.

[berdario]

I haven't read/fully processed everything, but if I wait to do that, I'll just end up being a bottleneck again 🤦 ...

@berdario : any chance you'd consider creating a pew org or something and handing over pew maintenance to it to allow a more distributed maintenance of the tool (also add folks to pypi etc. so they can make releases there?)?

I sent invite to make @pfmoore and @tjanez owners on pypi...

Creating a pew org is fine by me. Though instead of an ad-hoc org, I think it could instead be better to get it transferred to pypa?

@pfmoore I see that you're already a member of https://github.com/orgs/pypa do you have preferences in this regard?

Of course, there's a bit of overlap between several Python packaging tools, which is unfortunate. I'm not sure if Pypa would thus prefer to not get pew to be a member, or if instead this could be away to align future plans for the different tools.

Also, according to: https://www.pypa.io/en/latest/members.html#individual-membership

Every maintainer of pew would become a pypa member. I'm not sure if this is something that could be seen as a obstacle (since we have an handful of people with write permissions here in the repository, not everyone of which is still actively contributing... me included).

I can start the thread at https://discuss.python.org/c/packaging/14 or you could do it.... or we could just create the pew org

About creating an org:

I'd prefer creating it belonging to a business or institution (which one? pypa again? I guess that this way if there might be another gap in ownership, they'd be able to take control more easily, even if formally we would've created a separate, smaller org)

[pfmoore]

@pfmoore I see that you're already a member of https://github.com/orgs/pypa do you have preferences in this regard?

All PyPA membership would give is a github organisation. It wouldn't solve the problem of lack of maintainers. And honestly, I'm not sure I'd be in favour of accepting a project into the PyPA that needed the membership to address a sustainability problem. I'd strongly suggest getting the project active again before even thinking about PyPA membership - even if that means a bit of extra short term work¹.

Step one, which you're working on, is getting to a point where there is nothing that relies on a single person. We're working towards that on PyPI as we have you and me (and @tjanez assuming he accepts the invite) as owners of the project². The same needs to happen on github, but I honestly don't know what you need to do there, so I can't advise you. Can you not set up a pew organisation owned by your account and then add co-owners? Is that not a thing?

As regards my being a co-maintainer on this project, I will say, in the interest of being transparent, I probably won't be very active. I only use a rather small subset of the project's functionality these days, and for my own purposes, I'd be inclined to make rather sweeping changes in the interest of long-term maintainability that removed a lot of what I see as non-core functionality. For example, nix support and the pythonz integration. But that would likely cause problems for people who do care about, or use, that functionality, and I don't want to get involved in significant deprecation work like that. So I'll more than likely do very little beyond essential admin, which means a lot of the load will fall on Tadej, unless we (the whole maintainer team) agree on a more significant change of direction. I'm sorry if that makes things harder, but I don't want to leave people with unrealistic expectations here.

Realistically, I think we need some sort of clear roadmap of how the project will function, and develop, when it's "under new management". If we end up in a situation where new maintainers get added, but there's no clear policy beyond "keep things ticking over", things will simply remain unresolved. I'm not saying you have to get sucked into big policy debates, if you want to say "do what you like, I'm happy to leave that question to you" then that's absolutely fine. In fact, I'm assuming that's what you'd prefer. But I, for one, would like to know what people expect to happen next.

Footnotes

1. Full disclosure, I'd probably vote against accepting this project into the PyPA right now, because (a) I'm not sure it constitutes a "packaging project" in the sense I view that term, and (b) I'd have concerns that the maintenance issues wouldn't go away just because the project got accepted. ↩

2. But assuming you will still have little time to be involved, and given what I say below about my involvement, we are realistically still in a situation where the project's continued viability relies on Tadej - which is hardly an improvement. ↩

[berdario]

That's fair.

So, for creating an organization: pew is already taken: github.com/pew (and so is github.com/pewpew and github.com/pewpewpew 😬 )

alternatives:

github.com/python-env-wrapper

github.com/python-pew

@tjanez any preferences?

[pfmoore]

I'd go with python-pew, FWIW.

[tjanez]

Apologies, I don't have time reply to all the points above.

Just in terms of the name, I was thinking of perhaps going with "github.com/pew-org" for the organization and then the repo would be under "github.com/pew-org/pew". Thoughts?

Between the above proposals, I slightly prefer "github.com/python-pew".

[berdario]

Done: github.com/pew-org it is

I invited you as owners, and also created https://groups.google.com/g/pew-org since the organization required a contact email, and I wanted to void another single PoF

[funkyfuture]

i'd like to contribute a change so that setting up shell completions and modifying a shell prompt are configured separately, so one can choose to use only one of the features.

but would there be someone doing maintenance work atm?

i could also put some effort in other issues that maintainers consider essential for the survival of this tool.