Package development with or without own environment?

I find it a bit hard to understand environments in relation to package development. If I develop a fairly simple package and mostly want others to just clone (may register later) and use it, is there any reason to have its own environment for it? What is the main reason for specific environments? And if I have accidentally made its own environment, how does one best remove it again? Sorry for this basic question, the documentation seems geared to more advance use cases and I couldn’t find a very clear answer to this (beginners) question.

1 Like

People who clone the package will use their own environments, you don’t have to worry about that. All you need is a Project.toml file, which contains the list of dependencies for your package (*). The easiest way to write it is to go to that package’s directory, and julia --project=. then ]add Dependency1 etc.

This will also create a Manifest.toml file with specific versions of your package’s dependencies. That file has absolutely no impact on your package’s users. You can commit it in your package if you want, or not. It’s nice (for you) to develop/test in that environment: it already has the project’s dependencies available, and if you ensure that ]test passes before committing, then you know that you can always come back to that environment and the tests will pass.

Does that help? Environments are confusing at first, but they are a very nice design.

(*) And compatibility bounds, if you want to register it.

2 Likes

So environments are only for your own development?

Environments are generally useful for organizing projects (ie any kind of nontrivial work).

One disadvantage of putting all packages in the default (home) environment is that it increases the probability of holding back packages to some previous version because some other package (or a chain of them) have not updated their compat bounds (yet).

3 Likes

+1 on this. If you do everything in the default environment you will inevitably run into this. It’s much better to get in the habit early of instantiating new environments every time you start a new project IMHO.

1 Like

Good advice, thank you!