In a lot of projects, this is usually done via README. It tells you what running dependencies to install and how to run certain commands.

This can get harder to maintain as things change, the project grows, and complexity increases.

I see two parts to automate here: actually setting up the environment, and running the application or orchestrating multiple apps.

How do you address this?

  • Kissaki@feddit.de
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    2
    ·
    10 months ago

    Orchestration and containerization are heavy dependencies. I prefer few and simple requirements, especially on the environment.

    That only works well with tech with a defined or prevalent environment. Then it’s a matter of keeping docs up to date - like any doc.

    Using small scripts if necessary, and splitting off non central dev workflows helps keeping it simple and focused.

    • Cyclohexane@lemmy.mlOP
      link
      fedilink
      arrow-up
      1
      ·
      10 months ago

      Containerization is only heavy outside of Linux, and orchestration only makes sense when manual orchestration becomes too tedious (it’s easy to orchestrate a single app).

      Keeping docs for those things is very troublesome imo. You can’t feasibly consider everyone’s different environment, C library used, their system’s package manager and how it may package software differently than yours, and the endless array of things they may have already installed that may effect your app in some way. Sure, it’s not super common, but it’s hell when it does.

      But I suppose if your use case is very simple, like “just have nodejs installed and run npm start” then sure. But things can get ugly very easily.

      • Kissaki@feddit.de
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        10 months ago

        For toolchains like rust, go, c#, typescript/nodejs how would “things get ugly very fast” when making the toolchain an env dependency?