Release 1.0

[pathunstrom]

No description provided.

[AstraLuma]

Not blocking anything, but to discuss: what do you want in 1.0?

[pathunstrom]

Honestly, at the time I thought we were ready, but if we get the latest batch of PRs over the line, they'll be a great addition.

[AstraLuma]

With #106 merged, we're ready to get the ball rolling on this.

@nbraud is there anything you're aware of that needs to be fixed or implemented?

[AstraLuma]

Note: ppb/pursuedpybear#204

[nbraud]

I think I mentioned that on Discord a while ago, but there are some things we really ought to revisit before a 1.0 release:

• Documentation is a big one but, thanks to @astronouth7303, Add Sphincs-based documentation #130 should be merge-able soon.
• Getting rid of Vector2.convert, and making the constructor non-copying when possible.
  Handled by @astronouth7303 in Move to a non-copying constructor #142 <3
  Do we want to keep the Vector2(vector_like) “copy constructor”?
  It makes the dispatch in Vector2.__init__ somewhat hairy, and in all cases Vector2.convert should be preferred as it's more efficient.
• The expectations for subclassing Vector2 aren't specified; in particular, adding any attributes (say, making a ColoredVector) won't work without reimplementing almost all methods (at least the ones using type(self)(x, y)). Work in progress as Update expectations of subclasses #144
• Commit release scripts to the repository, review them, potentially publish from CI.
• Do we want to implement 3D geometry in the future? (At least @pathunstrom mentioned it)
  Is the current API well amenable to that? (For instance, can we easily share code and tests between 2D and 3D?)

I'm probably forgetting some things, but that's already a bunch of stuff.

[pathunstrom]

The last question can be set aside for later. We haven't needed it yet, but it's a future I considered at one point (thus Vector2 instead of just Vector).

As for subclassing, I mostly put a lot of the patterns there because they're best practice and less because I expect a lot of people to subclass this.

I'm mixed on the copy constructor, but @astronouth7303 is right, overloaded default constructors is pretty normal in Python land.

[nbraud]

I mostly put a lot of the patterns there because they're best practice and less because I expect a lot of people to subclass this.

I'm not sure what you mean there, but I think it's important that we are intentionally choosing (and documenting) what's expected of a subclass.

ppb itself subclasses Vector2 (though only to change its name & type).
If this is indeed the only subclassing we want to support, I think we should get rid of it: the whole dance around _find_lowest_{type,vector} has a maintainability and performance cost.

If we want to support people subclassing Vector2 (which might be reasonable?), then we should document what's the interface contract.

[AstraLuma]

With #142, what other blockers are there for a 1.0 release?

[nbraud]

@astronouth7303 I think it would be worth clarifying (and possibly adapting) what's expected of a Vector2 subclass for it to work correctly.

[nbraud]

Also, I think @pathunstrom made that comment on ppb/pursuedpybear, but it would be good to at least commit the release scripts in the repo and review them (or perhaps even build/publish from CI?).

[nbraud]

I made #144 to work on the inheritance stuff. :)

PS: Also updated the checklist of things we need to clear before release.

[AstraLuma]

Updated with the latest stuff.

What needs to be done?

[nbraud]

@astronouth7303 I believe we are good. The trigonometry issue I mentioned on Discord turned out to be a non-issue (see #164)

PS: Nevermind, I have some feedback.

[nbraud]

We seem to be using semantic versioning given our current releases & the use of ppb_vector ~= 1.0a2 (equivalent to ppb_vector >= 1.0a2, == 1.*) as a version constraint in pursuedpybear.

I think the 1.0 release would be a good time to commit to semver and document it.

Update: Done in #165, merged.

[AstraLuma]

Ok, so here's the big areas:

• Is the code in shape for a 1.0?
• Are the tests in shape for a 1.0?
• Are the docs in shape for a 1.0?

I think the answer to all these questions is yes. There's some odds-and-ends improvements we want, but nothing we can't make a minor version for. The documentation isn't super great for beginners? But also, I would expect the number of people that know vector math that don't know python to be small? idk.

We can also improve docs in minor releases.

[nbraud]

@astronouth7303 I agree the documentation could be improved; the API reference is pretty OK by now, but that a quarter of the documentation we need.

That said, I do not believe that should hold up the 1.0 release.

PS: I didn't mention the code and docs, but I believe they are both in shape for a release.

[nbraud]

There's also the change I requested, i.e. avoiding a repetition of the version number between setup.cfg, __init__.py, and git. The packaging documentation suggests using git tags as the authoritative source for version information, using setuptools_scm. Does that seem sensible to you two?

[AstraLuma]

bors r+

[bors]

Build succeeded

• FreeBSD PYTHON:3.6
• lint
• pep517
• macOS PYTHON:3.7.2
• FreeBSD PYTHON:3.7
• docs
• macOS PYTHON:3.6.8
• Linux python:3.6-slim
• Linux python:3.7-slim
• Windows python:3.6-windowsservercore-1809
• Windows python:3.7-windowsservercore-1809