Update publish-pypi.md with consistent usage for "test PyPI".

[ptressel]

Refer to "test PyPI" with consistent case and punctuation (with the exception of uppercase T when this appears at the start of a sentence).

[lwasser]

i know @ucodery is there sprinting too and am curious about his thoughts. I think i / wewrote it out this way because of this on the testPyPi website. I really don't know what pypi generally prefers but they do refer to the page as TestPyPI on that page so we might want to stick with that. let me know what you think @ptressel

[ucodery]

I definitely recall trying to normalize all these references 😅 . I don't recall settling on TestPyPI, but I never really checked how the site refers to itself. I recall going with either "test pypi" or "test PyPI" but don't remember which. I'll restate what I said during the sprints: I don't overly care how we do it but I would appreciate a consistent spelling. This is obviously easy to get out-of-sync on. And I wish we could make spellcheck catch it in the future! (Not sure that's possible).

[ptressel]

There is "prior art" for TestPyPI -- it is spelled that way in the Python docs. The actual website is test.pypi.org. Here is the reference:

https://packaging.python.org/en/latest/guides/using-testpypi/

In the current revision, there was one instance of "TestPyPI", but many instances of the expression "test PyPI". The former is a name, the latter is a description of its purpose. Since this is documentation, there is no need for "aesthetics", as in an English essay, where one might be advised to not keep using the exact same expression over and over. :D :D :D

One option would be to change everything to TestPyPI, but add a parenthetical note on the first use saying that this is provided to test package deployment, and note that the production PyPI should be used for one's fully tested package that is ready to go live.

I was going with the most common form in the current version, which is the one we picked at the sprint. Let me know if TestPyPI is preferable.

-- Pat

[ptressel]

Hmm...why don't I do a pass to switch to TestPyPI, so we can see what that looks like. Since we have the official doc now, we can peek at how they describe it.

-- Pat

[lwasser]

Hmm...why don't I do a pass to switch to TestPyPI, so we can see what that looks like. Since we have the official doc now, we can peek at how they describe it.

@ptressel @ucodery that sounds good to me!! let's use TestPyPI to align with his PyPA spells things!! many thanks!

FUTURE IDEA: This is of course for another issue / PR BUT there is this tool I use locally called Vale that @Batalex turned me on to. it's nice because you can create your own style guide. i wonder if there is a way to set this up as a ci check for the organization in the future? we could then have the style guide information in a single repo and use it across all of our repositories.

[willingc]

And hello @ptressel. Nice to see you sprinting here. It's been too long since I have seen you at a conference. Hope all is well.

[ptressel]

This will have a merge conflict with the previous PR for this file, which removed a near-duplicate line. When I branched this file, that PR was not yet merged, but it is now. I forgot that the other change was a separate PR, so re-deleted that duplicate line. Unless...maybe GitHub's version of git can detect that the later change is identical, and deal with it. The automated check says "Merging is blocked", but does not give the reason as a merge conflict, rather, "merging can be performed automatically" with review.

This branch also has two previous commits that are essentially replaced by the latest one. So if "squash and merge" is allowed, it would be cleaner to squash all the commits. The latest commit message has all the information, so if the GitHub squash process is anything like the command line rebase, the earlier commit messages could be edited out.

[ptressel]

Hello right back, @willingc ! I'm retired now, and have been just a titch embarrassed that I'm not working on some open-source project. (The one I was working on switched to doing simulation rather than hands-on work during the pandemic, and the simulation tool needs a GPU...which I don't have.)

[ptressel]

Thanks, @ucodery ! (Just yesterday, I was at a meeting of the "rules & bylaws" committee of an organization I belong to. One thing that came up was whether our "policy" committee should be permitted to offer wordsmithing help to folks wanting to propose resolutions. We used to have a resolutions committee that did that, but that faded away, on grounds that anyone can bring any resolution, and we should not alter their wording. I said, this was only done in collaboration with the resolution proposer, and they had control over the result. Someone else then said, anyone can benefit from good editing and proofreading. I followed that by saying, right now, as we speak, I am benefitting from excellent editorial advice on a technical document. ;-) )