DiamondLightSource / python3-pip-skeleton

Archived in favour of https://github.com/DiamondLightSource/python-copier-template
Apache License 2.0
5 stars 5 forks source link

Dev container features #90

Closed garryod closed 1 year ago

garryod commented 1 year ago

We should discuss the default features we feel are appropriate for the skeleton development container. As a baseline it would be nice to be on parity with the auto-generated python dev container, with:

Also included, but probably unwanted:

gilesknap commented 1 year ago

This PR comment should probably have been in this issue instead! https://github.com/DiamondLightSource/python3-pip-skeleton/pull/89#issuecomment-1325173207

garryod commented 1 year ago

Garry, you are way ahead of me now. I was not aware that there was an open devcontainer spec I like this overview page which describes 3 kinds of containers https://containers.dev/overview.

I think we have been treating the dev container primarily as the 2nd type "outer loop" container and that is why we have kept our extensions and tools to a minimum.

Part of the point of the inner loop container is that it is customised by the individual developer. Is it sufficient to use our devcontainer.json as the basis for individual developers to derive their own inner loop container?

There is the issue that a shared project should work for developers with different customisation and it is not clear where they could save their custom devcontainer.json. A workaround to this is the idea of a workspace container - not sure if you have looked at https://github.com/epics-containers/dev-u22-workspace ?

Ah yeah, it a GitHub + VSCode (i.e. Microsoft) thing right now, will be interesting to see if / how it grows over time.

In my head, the dev containers in our repos are "inner loop" containers, so that make sense why our expectations of included tooling don't quite align. It is quite possible we will need to ask prospective users of the skeleton if we wish to find out what is desired tooling wise, but we should almost certainly document the process for adding / removing tooling to / from the dev container.

Yeah, I've had a look at workspace folders and discussed them with @coretl; Whilst they seem well suited to controls type workflows, my previous experiences have been poor due to wide variety of base images needed for analysis type tasks (e.g. Python, C, CUDA)

garryod commented 1 year ago

From in-person discussion with @coretl @gilesknap & @GDYendell:

Discussion was had over the role of repository dev containers and workspaces. It was agreed that as addition of features to a repository dev container does not preclude the use of a workspace to develop the repo, a fairly small set of uncontroversial, high quality features should be added to the default development container. This set is yet to be decided upon

garryod commented 1 year ago

At present my suggestion is solely Common Utils. Any additions would be welcomed.

gilesknap commented 1 year ago

I've merged #92 I think we are good to close. Pls reopen if any further discussion is desired.