cogent3 / c3dev

cogent3 developer tools
5 stars 9 forks source link

Clarify dev environment and write docs #44

Closed fredjaya closed 11 months ago

fredjaya commented 1 year ago

The proposed development environments include using:

Should both approaches be supported and documented, or just one? Maybe a question for @khiron?

Once confirmed, can proceed with writing dev install documentation (i.e. remove current conda documentation)

khiron commented 1 year ago

The upside of Docker is that it gives us a baseline environment that will work on any system that can host a Docker container. This pushes the responsibility for the configuration of that down to the developer and their IT department. ie: Get Docker hosting to work, and the container should behave consistently and reliably on all platforms.

The downside of Docker is that while the container is running, it is consuming a fixed portion of the resources of the developer's system.

The upside of not using Docker and developing natively is that you have all the resources of your laptop available for the task.

The downside is that any configuration weirdness on the developer's system could impact development.

My vote is to support Docker so we have a known baseline environment and provide best practice guidance for native development (virtual environments, using pip freeze>requirements.txt and pip install -r requirements.txt) for those willing to tinker.

GavinHuttley commented 11 months ago

Bear in mind that nearly all the core-devs do not use Docker! There's also a performance hit from virtualising (at least on Apple silicon).

So, I don't see Docker as a universal solution. It may be the most expedient in instructing new devs to "do it in docker", but we should think about who our new devs will likely be and provide a "shortest path" to dev setup accordingly.

I predict new devs will be drawn from users of cogent3, i.e. they're doing genomic data analysis. For this cohort, it's highly likely that they are familiar with conda. So the key concepts are git+fork+clone+dev install+run test suite+git branch+git push+PR.

I do not endorse using requirements.txt (everything they need for dev is already configured in pyproject.toml).

So in my view, we need to encourage candidates to select the path to dev setup that works for them.

fredjaya commented 11 months ago

I've added a section about choosing the right setup, noting that both native and Docker are supported.

Tried to keep it succinct, but let me know if there's anything else that can be amended.

GavinHuttley commented 11 months ago

Excellent! I'm calling this done.