[crabbone]

Sorry for not being interested in what your library does, I like looking at how different Python packages go about packaging / installation / testing and other infra stuff.

Having a Makefile is kind of... unusual. A hand-written one is even less so.

Now, I haven't used Poetry a lot, but... your Makefile is all about using Poetry. Which is kind of fun since it alone is supposed to provide most of that infra stuff. Also, allegedly in a cross-platform way, but you kind of made it very Linux-exclusive by including some Bash, and, well, Make itself being a foreigner in the MS land.

Another funny part that I can see there is how Python (not very smart) community was fighting against removing integrations from setuptools to kill stuff like "setup.py test" or "setup.py install", but Poetry does exactly that. I mean, it's not on you, and it's not bad. I actually believe that that's the better way to do it. But you'll find a lot of Python (not very smart) apologists foaming in their mouth when telling you how you are supposed to use different utilities on your project and how pyproject.toml is supposed to be the connecting link between all of them. Which, turns out, you also have.

And, hey-ho! you are also using tox, while running tests from Poetry.

Another funny part is that you specify all your dependencies while including patch in the version. You are definitely not the only one, and it's a common thing in (not very smart) Python community, but it still cracks me up every time I see this. Like, the whole point of semantic versioning was that you are supposed to depend on the version of public API. So, in principle, any package needs to depend only on the major version. Minor version if you've done something stupid (like depending on features that haven't been officially released). And patch -- well, that should never happen. The cherry on top if the caret (^) in your dependency specifications. That's another thing that should've never happened. The >= was supposed to work like that (but that's not on you, that the not very smart community behind SemVer's fault).

Now, just to taunt you a little bit more: you do realize that the most sizable chunk of Anaconda Python users are in the research community, which is... sort of your target audience? Don't you think it's ironic that you don't make conda packages for your project? (And wait until you discover that virtually none of the infra code you wrote for your project will work well in that environment).

I'm not trying to disparage you. I see a lot of projects aimed at the science research world. Not being a scientist myself, ironically, I get credit in scientific papers for working on projects' infra :) I see a lot of struggle to keep up with the programming world from the scientific community, and I also believe I see some terrible choices (eg. Python) that are now put this whole group of people in front of a very difficult choice: either to continue with Python because there's some knowledge garnered, even though it's not enough by any measure, some still want to clutch the pearls... while a smaller part of this community wants to cut the rope before it's too late.

From what I see, in the research world, dealing with Python infra is an unmitigated disaster with lots of negative consequences. But the way forward is not very clear.

[bjornasm]

I think you have some interesting feedback and points, but I somehow think they get lost in some of the prose that arguably is against HN guidelines, notably:

>Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.

>When disagreeing, please reply to the argument instead of calling names.

>Please don't fulminate. Please don't sneer, including at the rest of the community.

[crabbone]

Where's "disagreeing"? I'm not disagreeing with the authors of Dtl on anything...

[MatthausK]

We took at least one immediate practical good piece of advice out of this which is that we should release a conda package and make sure that dlt works in it.

[claytonjy]

I wouldn't make it a high priority. If there's one thing I know about conda users it's that "no conda package available" has never stopped them. In fact they prefer to pip install inside their conda environment, and the only conda packages they use are the ones that touch Nvidia drivers (e.g. pytorch).

[crabbone]

> "no conda package available" has never stopped them.

Yes and no. They won't stop because they want to get things done, and the things usually don't involve honing the infrastructure. But installing packages with pip usually breaks conda installation, not even a particular virtual environment. (Usually pip nukes the setuptools that come with conda, and then once you want to install / upgrade anything in base environment, you discover that it's toast because conda itself depends on setuptools, but it's now broken and cannot be reinstalled).

So, in practice, if you give up and use pip to install stuff, it means that for the next project you will be reinstalling conda (and you will probably lose all your previous virtual environments). Kinda sucks.