Hypermodern Python Package

[pauleveritt]

Note: We've approved the work on the prototype. We're going to re-do it over here, on a branch, using "Diary Driven Development.

In this step, we'll make a new branch and bring over the work described in the first step of the prototype. Namely:

• A repo based on the Hypermodern Cookie Cutter's decisions
• With any adjustments we see fit (turning things off, replacing things)
• A actual Python package that can later be published on PyPI
• A Sphinx docs site with a diary for each step in building the Gallery and the website
• Use of poetry (versus conda)

[marimeireles]

Hi @pauleveritt thank you so much for all the work you put up on this to build the vision!
That's really amazing :)
I've read everything and thought about some things, the following reflects my personal opinion and not PyScript's or Anaconda's.

tech infrastructure:

Regarding the blue/black discussion on #22, currently PyScript is using black and we intend to tweak it to make it look "nicer". I'm of the personal opinion of using a smaller number o tools across sister projects. We can maybe decide what to do here and copy our results to the main repo.
In that sense, PyScript started with codecov, but I'm really not knowlegeable about it, maybe we should look into coveralls as @tildebyte mentioned and change it upstream.

Another question in this topic is regarding nox, I've never used it before. Do we need it? I'm asking because I can't think of an user case for it. For CI maybe...? Thanks!

Conda is more intentional: it’s less used per the PSF survey, and we want to show that PyScript isn’t tied to Anaconda no Conda.

I understand this point but I have some concerns. I wonder if a divergence here will cause problems regarding maintenance, basically if it will make it harder for us to maintain both things, e.g. if I have a package that exists only in the conda ecosystem then that's a problem for the poetry users (think about the extended ecosys. too, like conda-forge, my goal is not to dogfood conda necessarily[1]), besides that we can have divergent errors between the package's versions of poetry vs. conda. Maybe the question is should we shift everything to poetry? Bearing in mind if it's the best/most used solution to our users, specially the beginners.

hosting infrastructure:

Another question I have is regarding licensing and actual place where this repository is going to live. Is the idea to be something parellel to pyscript/pyscript-collective? Or to substitute it (literally rename the repo to pyscript-collective?

:::{attention} Package name? The PyScript ecosystem should adopt a prefix for add-on packages, as done in Django, Flask, Pyramid, etc. Presumably this package will be named pyscript-collective.

That’s pretty long, though. Perhaps PyScript should adopt ps- as the prefix? :::

IMO that's good.

code of conduct:

You think it's a bad thing to have people pointed to the pyscript email or other people from Anaconda? I'll understand if yes, but I think it's very important to have more than one place/person to reach out to in case of CoC breaks, etc. So we should open up for the community and ask for help =)

[1] we actually currently have an example like this where we're trying to use a package that's not available open source (it's owned by Microsoft) and I'm looking into making it open source by using conda-forge

Once again, I hope my points are not discouraging, I'm really excited about the progress and what I meant with them was to have a back and forth and understand your point and this whole hyperdrive thing that's new to me.
Thanks again Paul!

[pauleveritt]

Thanks @marimeireles for taking the time to do a detailed analysis. I also talked with Fabio this week on some of these topics. I'll break things out.

• Black. Agreed. I will accept any PyScript config. We can experiment here first if you'd like.
• Coverage. Agreed. I will start with what I have and switch to what PyScript does. We can experiment here if you'd like. Hynek had a good writeup on what he did.
• Nox. This becomes important when you make and publish a PyPI package. You can't trust your local environment. Mostly useful for maintainers, not contributors.
• Conda. Fabio and I discussed this. PyScript won't succeed if conda is first class and PyPI/virtualenv is second class. The Collective can help ensure that the primary way used in the Python community still works.
• Poetry. Adding to that, I don't mind ditching Poetry for just plain pyproject.toml and setuptools in a virtualenv. Poetry makes it nice for publishing. But there are alternatives, while keeping PyPI and common Python stuff.
• Repo. I am going to recreate my repo, step-at-a-time, in a branch in this repo. Everybody can review and comment.
• Package names. I know it seems silly and pre-mature. But if people start making a bunch of plugins, we'll regret not setting the right example. I like your ps-** suggestion. But, it means running it with pipx would be pipx run ps-ga which might not be as nice as pipx run psga.
• CLI. OTOH...your CLI project might become the runner. So...lots of intertwining points.
• CoC. I don't have a strong opinion on this. I think it's related to "who owns the PyPI keys?" It kind of feels like the GitHub organization should somehow constitute the governance, if that is you want people to feel PyScript isn't an Anaconda thing.

All good points, thanks!

[fpliger]

Excellent conversation! 👍 Just my addendum on a couple of points.

In general, the more we can reused things from PyScript core repo for the collective and vice-versa, unless it becames "a stretch and unnatural"

Conda. Fabio and I discussed this. PyScript won't succeed if conda is first class and PyPI/virtualenv is second class. The Collective can help ensure that the primary way used in the Python community still works.
Poetry. Adding to that, I don't mind ditching Poetry for just plain pyproject.toml and setuptools in a virtualenv. Poetry makes it nice for publishing. But there are alternatives, while keeping PyPI and common Python stuff.

We use conda on the main repo mostly out of force of habit on my side, not because it's an Anaconda thing or because it's needed. Poetry is a great tool and seems like a good fit for the collective. If in the future we start using things that makes conda a better fit, great. It's just another tool...

I also don't think we should give too much thought to "Conda is more intentional: it’s less used per the PSF survey, and we want to show that PyScript isn’t tied to Anaconda no Conda." That's not what makes PyScript tied to Anaconda. The fact that PyScript was created inside Anaconda and the initial core team was (is) mostly Anaconda employees is a much stronger tie to Anaconda that, with time and adoption, we will hopefully change. This is not new to Anaconda (Bokeh, Dask, and many other projects were born at Anaconda but are OSS projects governed by people and organizations not affiliated to Anaconda). The way we change this is by adding more diverse core developers/steering council members and through the governance model (not a tool).

With that said, pyscript-cli, the cli for PyScript uses Poetry and not conda 😉

Package names. I know it seems silly and pre-mature. But if people start making a bunch of plugins, we'll regret not setting the right example. I like your ps-** suggestion. But, it means running it with pipx would be pipx run ps-ga which might not be as nice as pipx run psga.

fwiw, pyscript-collect doesn't bother me too much but would love to hear others too

CLI. OTOH...your CLI project might become the runner. So...lots of intertwining points.

Yes! Lots of potential here...

CoC. I don't have a strong opinion on this. I think it's related to "who owns the PyPI keys?" It kind of feels like the GitHub organization should somehow constitute the governance, if that is you want people to feel PyScript isn't an Anaconda thing.

+1 (with the caveat that I mentioned above)