Should I turn a registered package into a package extension? What are the differences between them?

For example, if I have a base package and an extension package that is loaded only when some criteria are satisfied. And this extension package has been registered in General. Now that v1.9 include the “package extension” feature, should I turn this extended package into a package extension? What are the differences between them? Just whether there exists a Project.toml for the extended package? Can you register a package extension?

Package extensions live in the repository of a package, so they are not separately registered.

It is hard to suggest anything here without details (links to the package repos, so we could see how large and complex the codebase is, etc). I would say that given the fact that the extension package is registered, there is no harm in leaving it as is. But you can also deprecate the whole package and turn it into an extension.

I think it is best to use extensions when they require no additional user interface. Eg you have a package that defines

do_something(inputs::MyType)

and you could define

do_something(inputs::AnotherPackage.SomeType)

with a bit of internal conversion/glue code after AnotherPackage is loaded. But if additional API is needed, it may be better to have a self-contained extension package.

3 Likes