Setting up shared PyPI maintainership

[Technologicat]

I think now would be a good time to add you (@johnyf and @jdb78) as Pyan maintainers on PyPI so you'll be able to package new releases, too.

For that, I'll need your PyPI usernames, so I'll know which users to invite. You can post the username here, or if you prefer to tell me privately, my email address can be found in pyan's setup.py.

Just in case if you haven't yet registered a PyPI account, you can easily do so on pypi.org.

[jdb78]

Thanks a lot for this. It is the same as for GitHub: jdb78

[Technologicat]

Invited!

[Technologicat]

FYI - I just packaged the latest code as version 1.2.0. But you'll be able to make the next one :)

[jdb78]

Would it be a good idea to create PyPI releases automatically through github actions, once one makes a new release on github?

[Technologicat]

Yes, why not.

If you're familiar with how to do that, go ahead :)

[amw007]

Hi @Technologicat, @jdb78,
I would like to contribute or maintain this project. I'm new to contributing to OSS contribution and I stumbled on this great project for one of my use case. And, it bit broken.

Please let me know if I can do so. PyPi Uname: am007

Thanks & Regards,
A M

[Technologicat]

Hi!

Thanks for the interest!

Yes, you can contribute. While I haven't been maintaining Pyan, the repo has not been archived yet, so if you make something, we can push the changes here (best done with a pull request) and then upload the new version to PyPI.

Here are some ideas where to start contributing:

1. To allow Pyan to become useful again, it needs to support current versions of Python. An issue with any project that depends on Python's AST (abstract syntax tree) representation is that the AST often changes when there is a new minor release of Python. See Add support for Python 3.8 and later #51.

   I happen to have been maintaining other projects that depend Python's AST representation, specifically unpythonic and mcpyrate. Based on what I know, I could make a list of the AST changes that have happened in Pythons 3.7 through 3.12*. You could then look at how Pyan's analyzer needs to be changed to account for those changes.

   Let me know if you want to start with this. We can discuss plans here.

   (* I haven't added support for 3.13 or 3.14 to my other projects yet, that's something for later.)

2. There are currently some pull requests which have not been resolved, mainly because I have not been actively maintaining this project.

   You could start by reviewing the existing PRs if that sounds like an easier starting point. Let me know if this is what you want and we can discuss details.

3. Pyan's build system (setuptools) is deprecated, if not already out of support. To be able to build new packages, the project should be migrated to another build system.

   I migrated my actively maintained projects a while back. In those, I use PDM, thanks to a drive-by contributor who happened to be familiar with that. Other options I'm aware of (but have no experience using) include uv and Poetry.

   If you're familiar with any of those, great - but if not, I can supply some examples for PDM. Let me know if you want to start here.

To sum up, please first let me know what you would like to do, and we can discuss further.

[amw007]

Hi,
Thank you for the quick reply for my request, :).

I'm well aware of and using the uv for the projects I've working on.
And, as I forked the repo and cloned, I've migrated to uv ( as you've asked, I've raised a PR: #104 ) in the first place.
If you've any objections or suggestions I'm open to it.

And, for the AST changes, I needs to understand more, so, will comeback on it.

[Technologicat]

UV - great! Let's use that, then. :)

PR reviewed, as stated in #104 and in #103.

Let me know if you need help with the AST. The documentation situation is a lot better than it used to be, now that what used to be the external Green Tree Snakes Python AST documentation project, was merged into the official AST docs a few years back. The official docs are nowadays a great starting point.

If you want a practical example of a handler that supports most AST features (all except type annotations) up to Python 3.12, you could look at mcpyrate.unparser, which backconverts from AST into source code. It's ~1000 SLOC, mostly because Python's grammar is huge. The code is actually very straightforward.

Pyan needs to do a bit more to build the call graph. The core isn't that complicated here, either, but there's some extra complexity due to questionable design decisions on my part. I should have got rid of the last_value mechanism in Pyan's analyzer when I ported the code to Python 3, but at that point, I didn't have a clear picture of what responsibilities are sensible to give to a static analyzer, instead of a dynamic one. I'll gladly explain in more detail, if you're interested in simplifying the analyzer.

(I'm maintaining my own unparser instead of using packages such as astor or the stdlib ast.unparse added in Python 3.9, because I need some extra features that are specific to an environment that has a macro expander.)

EDIT: mcpyrate.unparser supports also type annotations, I had forgotten I had added that. Though it seems to be missing for function return values. I wonder what else. I suppose I'll have to fix that later.