I just want to weigh in and say I think this sounds like a great idea in principle.
Alright, it looks like the only thing left is to decide whether to have this under PyPA or create a new org.
FTR linking a few more threads outside of this discuss thread:
Oh, and a follow-up question.
@pradyunsg was concerned that the name
pypi-action may be misleading. What do you think? Its primary function is to just do
twine upload and that’s it. In future, I think, I’ll update it to also publish fancy status updates to Checks base which doesn’t change the main purpose.
Any ideas on this? When I was thinking about naming, I thought that putting
twine in the name is not a good idea because it’s an implementation detail and it may be substituted by anything else implementing the same thing in future (if needed, of course). Referring to
pypi seems logical as when a user wants their automation to put a dist there it’s what they think about first.
It’s important to have a good non-misleading name from the beginning because it’s going to be published to the Marketplace and have its own fancy page there.
It should be well-memorizable.
pypi-upload? That’s pretty explicit and unlikely to be misunderstood. It’s also better than something generic like “action”.
As for PyPA or a separate org, I don’t honestly mind. I’m assuming you’re not suggesting that maintenance of the action be taken over by PyPA, so putting it under the PyPA org seems fine. If we get a flood of other actions, we can move them to a separate org when it becomes a problem.
First of all, I want to keep
-action suffix convention because:
- It seems like a lot of other actions do so
- It makes it easy to identify the action repo in the file system on your local machine among other repos because it carries context/metadata
- On GitHub, in repo lists it’s better distinguishable as well. Even if it’s a separate org, we may want to have some helpers or something related which wouldn’t be an action.
I wanted shorter name, thus I didn’t add
upload there + I think upload is the only thing one would do with PyPI in the context of Actions.
However, I’m not against
pypi-upload-action. Or maybe
pypi-publish-action. Above paragraphs were to just explain my motivation
Yes, maintenance is on me, unless somebody would like to join, of course
I see a few (potential) problems here.
- Given that it’s still a beta feature there would be some bugs. For example, when I published
ansible-lint-actionto the Marketplace, that page was only visible to people who have access to Actions, nor was visible to them in the search. However, they were having access to the organization where Actions were enabled. Of course, GitHub team has fixed that but this demonstrates that we can hit something unexpected if we publish
pypa/pypi-actionand then move it to some
- When users refer to Actions, they use repo slug (
pypa/pypi-action) and once repo is moved the behaviour is undefined: what would happen to those users’ workflows? How would it affect the Marketplace posting? And so on.
If these will be official PyPA actions, it seems like they should be under the PyPA org. This would also make permissions management easier (though this issue is secondary IMO). An org having lots of repos doesn’t seem like a problem to me. Is it?
Regarding the name, it seems like a common prefix (e.g.
gh-action) would be more useful than a common suffix for locating and sorting the relevant repos. I’m not sure if being a suffix is the important part or simply having a common substring (prefix or suffix).
I only saw suffixes so I’d like to stick to that and avoid https://xkcd.com/927/ as much as possible. GitHub’s search/filter works on any substrings anyway.
Given that the feature has barely been released, I think it’s okay to choose a naming convention that works best for us. (I wasn’t advocating for a standard.)
FWIW, I seem to see a fair amount of variety anyways in the names people are using. Here are some others (prefixes:
(This also suggests you can have multiple actions in a repo, so it’s not just one-to-one.)
I also agree that
pypi-publish would be clearer and more future-proof than just saying
Does the action only support uploading to PyPI? IIRC Twine supports specifying an index (I think it calls them repo?)
Agreed - it seems like there’s a rush here to set in stone things that we haven’t really had much experience with. I get that people will end up with the org/repo name in their workflows, but that seems to me more like an issue with Github actions (not supporting moving actions flexibly) and something we (or someone) should be flagging to them, rather than ending up stuck with decisions we make before we have any practical experience.
Okay, yes, there’s different conventions to this, but
-action seems most used and let’s just say it’s my personal preference.
Technically, it’s possible. You can even create an action right in your project and use it there.
Only if you have one-to-one you can publish it to Marketplace and have a page like https://github.com/marketplace/actions/ansible-lint.
This also comes with Git tag based versioning which you cannot do (and is not supported by Marketplace) with multiple folders with multiple versions in Git because tags point to the version of the whole repo.
And putting this on the Marketplace is one of the end-goals I have.
It’s also worth mentioning that Marketplace takes metadata like URL slug and some defaults from
Dockerfile labels. This Dockerfile should be in the root of an Action project. What users will use in their workflows is repo slug, not what’s in the marketplace URL, though.
It looks like you don’t yet have access to Actions (my guess based on the fact that you don’t share marketplace links). If yes, I’m here to remind you that you can add yourself to the waitlist here: https://github.com/features/actions/signup
That’s its main purpose. Ideally, Actions should follow UNIX philosophy of doing one thing good which also makes them well-composable allowing end-users “play Lego” with them
Twine supports setting that via env vars. My demo uses exactly that to modify the upload target: https://github.com/sanitizers/octomachinery/blob/33fc17e/.github/main.workflow?short_path=c1c2d49#L16-L24
It’s just a hypothetical example, I didn’t test it personally. And also they are known to fix such problems quite fast.
But still having ended up with a misleading thing in user workflows may be confusing long-term.
This also has the same issue as moving repos or renaming orgs/accounts. Short-term, GitHub creates redirects but what happens if someone else creates a repo with slug matching the old location? It’s a potential hijacking point.
FTR: I’ve been pretty busy with real life lately. I’ve been responding to @webknjaz over chat on a different app but not here, since I’ve not had the time to keep up with discuss.python.org, GitHub or other mailing lists in the past few weeks.
So what do we do now?
Anyone? I’m ready to have it up and running…
Have you updated your proposal based on the feedback you received so far? If you listen and incorporate people’s feedback, that could help to build more support for you proceeding.
I think so… If not, please point out what I missed.
Okay, where is the updated version of your proposal?
Oh… the proposal. I misread that. Alright. I’ll try to update that.
I was just basically waiting for some sort of decision on where to host repos…
I’ve added some bullet points as a summary.