Package List?

[rbeyer]

Where shall we keep our official package listing?

The Astropy package categories seem like a very reasonable model, but most importantly they keep track of what is what via this file: https://github.com/astropy/astropy.github.com/blob/master/affiliated/registry.json

You'll see that it is in their webpage repo, so that their user-facing page (URL above) is automatically populated. Basically, if you want to propose an Affiliated package to Astropy, you put in a PR on that registry.json file, which triggers their Coordination Committee to start a review, and if the review passes, the PR is merged, and the package is officially an Affiliated package. We need a listing like this.

I like the idea of having it in the webpage repo, if someone is knowledgeable with the Jekyll engine that GitHub Pages use, that would be great. The planetarypy org does have a planetarypy.github.io page webrepo (but it still looks like the default page from 5 years ago, and I think things have changed with GitHub pages since then), that we will eventually use.

Maybe it is easiest for now to just have that registry file in the TC repo, and if we get the webpage working, we can think about moving it there?

What do you think?

[AndrewAnnex]

I could also recommend Hugo as I found Jekyll pretty hard to use when making my personal website, using GitHub actions it should be possible to emulate how GitHub handles rebuilding Jekyll pages (I saw a blog post a few weeks ago, I’ll post it here when I find it). Unless we want to keep using Jekyll

-Andrew Annex

On Nov 16, 2019, at 1:43 PM, Ross Beyer notifications@github.com wrote:

 Where shall we keep our official package listing?

The Astropy package categories seem like a very reasonable model, but most importantly they keep track of what is what via this file: https://github.com/astropy/astropy.github.com/blob/master/affiliated/registry.json

You'll see that it is in their webpage repo, so that their user-facing page (URL above) is automatically populated. Basically, if you want to propose an Affiliated package to Astropy, you put in a PR on that registry.json file, which triggers their Coordination Committee to start a review, and if the review passes, the PR is merged, and the package is officially an Affiliated package. We need a listing like this.

I like the idea of having it in the webpage repo, if someone is knowledgeable with the Jekyll engine that GitHub Pages use, that would be great. The planetarypy org does have a planetarypy.github.io page webrepo (but it still looks like the default page from 5 years ago, and I think things have changed with GitHub pages since then), that we will eventually use.

Maybe it is easiest for now to just have that registry file in the TC repo, and if we get the webpage working, we can think about moving it there?

What do you think?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[godber]

From the content and template management perspective all of these static site generators are roughly the same. The major way they differ is how much of a hassle it is to get the generator going and keep it going. This one fact is why I've recently come to prefer hugo. I second the use of hugo for this purpose.

--

Context:

I've created any maintained probably a dozen sites with Jekyll (Ruby), Hugo (Go), and Pelican (Python). I probably also created the original Jekyll PlanetaryPy site.

[AndrewAnnex]

looks like there are a lot of github actions for hugo related things, I haven't been paying attention to github actions, but I could test it out in a few days and report back. see https://github.com/marketplace/actions/hugo-setup

[rbeyer]

That would be great, @AndrewAnnex. I don't want to sidetrack us into website design, but if it is easy to set up something minimal, with a similar registry.json that we can use, then it is something we don't have to change later.

However, I'm also fine with just having a bare registry.json file in the TC repo for now, and we can migrate it later.

[AndrewAnnex]

I should be able to find some time next week to prototype something, I think the wiki or a markdown file would be a fine place for this until a website is set up I just read the top of this issue, I am not sure if we need something that fancy or automated but maybe we can do something similar with a pull request template

[michaelaye]

Let me put in a vote to use yaml as general config file format for all things that are being edited by humans. It's the standard used by travis and many other libraries and is much more readable and editable than json (I love Python because I hate brackets).

Here's how the registry file looks using yaml:

https://gist.github.com/1ba7d47630890ea090d87b62703b78e0

[rbeyer]

I don't particularly care what format the file is in, but I feel like these should be the guiding principals:

1. Depending on what simple web front-end we can stand up on planetarypy.github.io, it should be 'readable' and ingestible by that system.

2. Since we're a Python project, seems like we should use a format that can be parsed and written by tools in the Python Standard Library (so csv, configparser, json, etc.).

3. Human-readable (so not pickle, sqlite3, etc.).

[michaelaye]

I'm not very keen on enforcing standard library only, simply because we have to take care of other formats in any case, but if people insist, I can live with configparser, even so it's a dumb thing. Not sure it can actually do the array of items like we have in the astropy registry? "Since we're a Python project" sounds like a really good argument to object to json. Btw, I'd also be for TOML, as it seems to be picked up by quite a few, including Hugo, pip, pipenv, poetry, and tox.

[rbeyer]

In our meeting today, we agreed to start simple, and let this evolve. For now, only humans need to parse this list, so the only requirement is that it be written down, and we will keep this list in the main TC repo's top-level README file. Once we actually get a web page going, or have aspects that actually need to machine-parse such a list, we will migrate 'the list' to another file and file type.

[rbeyer]

Addressed in #19, if it gets merged.