As asked by @weaverba137 over at astropy/astropy-project#255 (comment)

Is there a way to know what upstream dependencies Astropy currently supports (equivalently: is being tested against), independently of tracking down the testing configuration files and reading those? If that did exist, one could conceive of packaging it in e.g. JSON or YAML format, then dropping those versions into templates of e.g. setup.cfg, tox.ini, .readthedocs.yml, ci_workflows.yml, etc.

Note: "Astropy" could be generalized to any upstream Python dependency that has similar layout as the template, perhaps.

I don't think we actually mention you need to have a git repo for setuptools_scm to work.

https://numpy.org/devdocs/dev/depending_on_numpy.html#build-time-dependency

If one runs

pieceofcake gh:OpenAstronomy/packaging-guide ./output_directory

and chooses the default answer to every question, apart from choosing '1' for the license selection, you should get the BSD clause 3 license. packagename/licenses/LICENSE.rst and README.rst have the GNU GPL v3+ license selected however.

We don't automake a git directory, but it is expected (#1), having a ignore would be very useful?

Distutils is dead, it should be setuptools. Probably should give the whole page a 🧹 while we are there

Our CI isn't being run on 3.12 yet.

GitHub Actions has been gaining a lot of traction, so it would be really helpful for the package template to already have configuration files for GitHub Actions built-in. That would simplify the process of setting up continuous integration testing for people who end up using the template for a project that ends up being hosted on ye olde GitHub.

Since there's a chance that some projects would end up being hosted on GitLab or elsewhere, it might be good to ask if the user wants to have these configuration files automagically included or not.

I'm also wondering if setting up GitHub Actions in the template would help allow the template itself to be (meta?)tested with GitHub Actions, but that's outside the scope of this particular issue.

Currently blank:
https://packaging-guide.openastronomy.org/en/latest/scripts.html

Things to cover:

• How to write a command line function that can parse arguments.
• Adding entry points in setup.cfg
• Testing those entry points

The page on how to include data in a package still needs to be written. Just to brainstorm, some of the topics could be:

• where to put data files
• accessing files (probably using pkg_resources?)
• dealing with large data files with git-lfs (and any good alternatives to git-lfs)

I'm also curious if there's a way to store data files on, say, the Zenodo online archive so that they can be downloaded during package setup or installation.

Seems the tox test uses pytest to look inside packagename – is that right?

Should that be a key in the template?

https://www.pyopensci.org/python-package-guide/ , e.g., https://www.pyopensci.org/python-package-guide/package-structure-code/intro.html

The page on continuous integration still needs to be written. Possible topics include:

• How to decide which CI platform to choose
• Using GitHub Actions
• Setting up Azure Pipelines
• Travis CI
• Circle CI
• How to cache large data files in tests (see also #7)

I'm working on a package with a name that's already registered on PyPI. What's the correct usage of the package template when you want to use an alias on PyPI, but you want to import the package under the simple name?

Mainly because otherwise GitHub doesn't know what the license is.

Particularly:

• https://github.com/OpenAstronomy/packaging-guide/blob/master/docs/ci.rst
• https://github.com/OpenAstronomy/packaging-guide/blob/master/docs/scripts.rst

Motivation: Astropy cannot reroute people from package-template to this site if this site appears unfinished.

Blocks:

• astropy/package-template#519

https://github.com/scientific-python/cookie is the cookie frontend to the excellent https://learn.scientific-python.org/development/ resource. It's more actively developed and more fully featured. Rather than duplicating effort, should we upstream the best parts of this packaging guide to https://learn.scientific-python.org/development/ and https://github.com/scientific-python/cookie and then deprecate this repo?

(Note: also impacts https://github.com/astropy/astropy/blob/main/docs/development/astropy-package-template.rst)

To the authors: this is a great guide! I've been learning how
to get sphinx to produce documentation and it's working great!

The section entitled Setting up ReadTheDocs contains some
code for the .readthedocs.yml file to be used when setting
up the ReadTheDocs documentation.

However, it seems there is a problem with the indentation in
the example provided, and when I tried to build the file using
this I ran into a set of compilation errors.

I cloned the repo and made a fix to the in the docs/docs.rst file
and this now compiles OK.

The link is here.

Hopefully this can help people using the guide!

Cheers,

Alex

https://github.com/pypa/setuptools_scm/#retrieving-package-version-at-runtime

https://readthedocs.org/projects/oa-packaging-guide-preview/ seems to indicate that the default branch is still set to master, so the readthedocs version of these docs is out of date. I think it needs changing to main.