Stem is unmaintained!

[kkarhan]

As hinted by me in this issue re: nyx and confirmed by @atagar as per his comment both stem and nyx are unmaintained.

I hope @torproject-git will select either a new maintainer, set them as archived or otherwise take care of them.

[gk-tpo]

So, here is what ideally happens from a Tor Project side: Both nyx and stem should be archived on Github. Then we'd take patches against stem via our maintenance branch on Gitlab: https://gitlab.torproject.org/tpo/network-health/stem/-/tree/maint?ref_type=heads. The flow for stem right now (which is okay for us) is explained on https://stem.torproject.org/.

For nyx we don't plan doing any releases and for stem we do bugfix/maintenance releases until we transitioned away from it our tools and the new world with arti (https://gitlab.torproject.org/tpo/core/arti) is a reality.

However, the call what to do with both projects, nyx and stem, on Github is something @atagar has to make.

[emdee-is]

@gk-tpo Who has write privs on this repo besides @atagar ?

Instead of archiving it you can mirror it on github. This is where it's known to be.

Do you have commit privs on that repo?

I don't see an issue tracker on https://gitlab.torproject.org/tpo/network-health/stem/-/tree/maint?ref_type=heads

It says 1.8.3 released last week: was the test run_tests.py --integ --target RUN_ALL run before it was releaed?

test/network.py should not use 9050 as a port as tor may be running on it.

The tests should check the existence of /proc/sys/net/ipv6 before doing anything with ipv6 as you may be on an ipv6 disabled system.

[atagar]

I don't interact with Tor's Gitlab. Moving Stem's canonical home there would remove the only person who replies to tickets or merges patches so that's probably not a good idea. ;P

[emdee-is]

The project should migrate away from setup.py

You can use these as starting points for both master and maint:
setup.cfg.txt
pyproject.toml.txt

@atagar are you the only one who has write privs on this github repo?

[atagar]

@atagar are you the only one who has write privs on this github repo?

No. GK, Juga, Silvia, Alex (ahf), Nick, George (asn), Mike, and David Goulet do too.

[emdee-is]

Thanks; I looked at the 1.8.3 gitlab code and there are some small changes relative to master from cryprtography renames and some data updates but the unit tests do not run cleanly for me. There's no issue tracker there. And I'm concerned for the coding style: I see no attempt at backwards compatability, the usage of == in requirements.txt and no double imports to deal with namechanges in imported packages. The project should never use == in requirements.txt given how many distros it's in.

The differences to the maint branch of this repo however are very substantial. What's the plan for that branch? Could you tell us in the README? If GK has commit privs here, maybe the best thing is for GK to mirror this repo into gitlab and help with the issues here...

Now we have 3 stems: now what?

Personally I'd like to see GK merge his patches into master here, and he can mirror master to gitlab, and then work on merging maint into master and dealing with any issues here. @atagar : your thoughts?

[hendursaga]

Just a suggestion, but perhaps pin this issue?

[atagar]

I'm sorry. On reflection Georg is right, this project should move to Gitlab.

Pinned this issue. Thanks for suggesting that, hendursaga.

[Vizonex]

Sorry if I am asking about this library over a year after this issue has been posted I thought making an asynchronous version called aiostem which would be an asynchronous version with updated features and python2 being fully dropped out of the equation but I didn't want to utilize any obsolete techniques and arti is still in it's beta stage with no good relative ties to python or even asyncio yet. Before I attempt to bite the bullet on this project idea that I had in mind, should I try using the new arti-rust library and bind it with pyo3 or is there any other suggestions that others might have in mind for me?