Closed rbeyer closed 4 years ago
PRO to start with pvl: Trevor seems to be eager to help.
CON: It feels like a very slow start for me, considering how much, I would consider, useful stuff is out there.
Let's discuss...
The TC expressed the wish to start with a blank canvas, so I guess the next question is, if we start with PVL, we need to figure out if it should stay an AP (affiliated package) or become core. Do we need another GH issue to start that battle or here is fine?
I think that's a downstream question. If we want to use pvl
as our test, then let's work on shaping it into an 'Affiliated Package.' Once it passes that bar, then we can discuss whether it stays that way or gets pulled into planetarypy
. One step at a time.
So maybe the first thing we really should do is build something like https://github.com/astropy/package-template for planetarypy
In our meeting today, we agreed that the first 'code' that we build should, indeed, be a package template for Affiliated Packages. Michael volunteered to either get a new repo going, or use the existing cookiecutter-pypackage repo (but I think it has an awkward name, I know why it is named this way, I just like the cleaner 'package-template').
The package-template is moving along.
I want to reactivate this and ask about affiliated packages, and see if folks have an opinion here. I think we're close to being able to reasonably manage our first affiliated package application. Is there anything that would prevent us from taking an application and attempting to run the review machine?
At the April Meeting we decided that we could submit pvl
and run the process. Since we are now "doing things" this Issue can now be closed.
I feel like the title says it all.
However, I have a suggestion: I think we should pick a package, and make it
planetarypy
compliant (whatever we define that to be), and then incorporate it as the firstplanetarypy
package. This will make us conform to our own standards, before we admit it to the project. And then we can go through the process of including it inplanetarypy
which will work out additional kinks.I think we also need to accept that the existing repos in the planetarypy GitHub org are not automatically members of the
planetarypy
package (they have a grandfathered status, clearly), however, I think they are excellent first candidates for this process.In fact, I think the
pvl
library would be a great first candidate.