Consider replacement of Make and Makefile

[aaronsteers]

In this PR

• chore: Remove Makefile #6488

We removed Makefile. I'm opening this discussion to explore what (if anything) might replace that in the future.

Some options we discussed in our Codeshare meeting today (Jan 5, 2022):

• Option 1: Don't replace. (Rely on Contributing docs and/or CI workflow files.)
• Option 2: Replace with a simpler/cleaner make.
• Option 3: Replace with tox.
• Option 4: Replace with nox.
• Option 5: Replace with something new, especially something that can also interop at the CI layer more natively.

Of those options, I think I personally lean towards "cleaner Make" or "something new". Happy to explore any options, and (as discussed) this can stay a low priority / slow burn discussion. No rush to replace as of now.

[sbalnojan]

@aaronsteers I didn't notice that, I was quite happy to have a "build docs" command inside make, so I'll offer an opinion.

IMHO for open-source projects it is even more important than for "traditional in-house development" to have super quick setup 6 dev functionalities for new/existing contributors (https://www.thoughtworks.com/insights/blog/praise-go-script-part-i is pretty much my perspective & way of handling these).

So I would urge to have that kind of functionality wrapped into something basic and simple. If you feel make doesn't quality, I'm a big fan of any of these two options:

• native bash + docker
• https://batect.dev/ (requires docker + Java, java sometimes is a downer for Python developers, so maybe not the best option)

And I would second your point about having that interwoven into the CI workflows.

[WillDaSilva]

For the docs:

• Convenience script to build & host Meltano docs #7195

For much of the other contributor concerns (e.g. building/installing the meltano wheel, running the tests, etc.) having scripts (or Makefile commands) doesn't do much to help because the user still needs to have a proper Poetry/Yarn/Nox/etc. setup, and if the commands being run are obfuscated, it can make it more difficult to know what's required, and/or why it isn't working properly.

That's not to say that we shouldn't strive to make improvements/simplifications in this area. It's just a difficult balancing act of many objectives, and the existing tooling in this area leaves something to be desired (e.g. there's no good way to run GitHub actions locally).

[aaronsteers]

I do miss having a Makefile, specifically for all repos to house a generic entrypoint for test, lint, and autoformat.

I ran into Pants again today and started considering if this could be a nice (and more modern) replacement.

https://www.pantsbuild.org/docs

[WillDaSilva]

Pants seems more like a replacement for Poetry, and is more of an all-in-one build/lint/etc. tool. Much more than something like Make that merely calls the tools we use, Pants would overhaul quite a bit, and possibly limit us to the tools it supports. That said, I haven't used it, and don't know much about it. I found this post about integrating it with Poetry to help you transition over to it.

If getting Make or something like it back into our repositories is a priority, I can find some time to figure something out for that. This does become easier to solve if we have fewer repositories.

[WillDaSilva]

Also worth noting that Pants is a monorepo management system. I've been exploring and experimenting with transitioning Meltano over to a monorepo for several weeks now, and using Pants for this may be worthwhile. That said, it goes well beyond the scope of this discussion.

[aaronsteers]

Thanks for these thoughts. I wouldn't push hard for Pants specifically, and your counterpoints about complexity, relative lift, and relation to Poetry are all helpful framing.

[WillDaSilva]

We should consider https://github.com/nat-n/poethepoet as a Make replacement. It seems to integrate well with Python and Poetry, yet isn't limited to them.

With it with can run shell commands/scripts, Python functions/scripts, and build composite tasks that are made up of other ones, e.g. a lint task that is composed of a call to mypy and ruff.

It has good cross-platform support, seems easy to use, is simple, lets us supply arguments to the tasks, handles environment variables and .env files, and lets us provide help text for each task it can run. The only way in which this loses out compared to Make as we were using it is in is that it isn't obvious that this tool is there unless you read e.g. the contributor documentation, whereas a Makefile is a well known thing that can be used to run tasks (even if it isn't clear what tasks are available).

Ideally we could just run poetry run <task name> instead of poetry run poe <task name>, but that isn't supported yet. I found this issue related to it, which is how I learned about poethepoet:

• Saving custom scripts in pyproject.toml (alias npm run) python-poetry/poetry#2496

[aaronsteers]

I had heard about Poe but hadn't really looked into it before.

I love that it integrates with the Poetry venv and allows task definitions directly in pyproject.toml: https://github.com/nat-n/poethepoet#define-tasks-in-your-pyprojecttoml