Updates to the stack package template: standalone packages, base dependency choice, and __init__.py

The stack_package template, our starting point for new EUPS packages and documentation of best practices, got three useful updates today:

  • Support for standalone packages.
  • Choice of base dependency.
  • Elimination of unnecessary __init__.py files.

Support for standalone packages

Up til now, the stack_package template assumed that all packages are part of the LSST Science Pipelines. This isn’t the case, and in fact, Telescope & Site is working on EUPS packages that aren’t part of an integrated stack. Such “standalone” packages ought to have documentation that can be deployed to its own site, rather than be compiled into https://pipelines.lsst.io.

Now there’s a new stack_name template variable that lets you select the stack that a package is a part of, or None if the package stands alone.

The example_standalone example shows off this package layout.

Choice of base dependency

The role of the “base” package is to be the EUPS dependency in the table file that, in addition to its own features, also provides implicit dependencies on common third-party packages. The default for LSST Science Pipelines is the appropriately-named base package. But to support Telescope & Site, which doesn’t need all the features of base, we’ve added a new base_package template variable that lets you switch to sconsUtils instead.

Farewell __init__.py

You know all those __init__.py files that do nothing but call pkgutil.extend_path and import lsstimport? Well, I have it on good word that we don’t need these anymore. In Python 3, __init__.py files are no longer needed to establish a package. So we’ve dropped these files from the template.

Now, the template still keeps the __init__.py of the module itself. This file is still useful for establishing public namespaces so it’s good to keep it in the template.

1 Like

This is great! When working on packages, should we remove the unnecessary __init__.py files then? :slightly_smiling_face:

I don’t see a reason why not. Obviously, test it first :slight_smile: