https://pantsbuild.org/ logo
Join Slack
Powered by
I'm curious what is the typical approach to managi...
# general
l
I'm curious what is the typical approach to managing requirements in a pants monorepo. In particular, a new requirement. So let's say I open a python file and I want to use a new library. Pants hasn't seen it before, so it won't be in my `./pants export`ed venv. It's also not in my requirements file. So do I add a line to my requirements file, then 
export
, then my interpreter should be updated? Just wondering what everyone is using as a workflow. And what about separating requirements for different areas of the repo? E.g. do you have a top level requirements file, then one in each module? Are you using 
pyproject.toml
? Again, in each module? Or just one for the whole repo.
e
If you don't have a strong reason for willy-nilly requirements, I suggest clamping down. Only if you absolutely must entertain different source depending on different version of 3rdparty should you go there.
l
You're saying just keep it at the top level.
e
I think physical organization is overblown. But sure. The key is 1 set.
l
If that's the case, is there a strong reason to use an exported venv over the normal venv? If you only have one set of requirements, they will essentially be the same and doing export just adds a step.
e
I'm not sure how an exported venv is related. What do you use it for? An IDE?
l
Yeah. In my IDE.
e
Ok. I personally just re-export now an again when I notice a missing dep in the IDE. That's all I use it for though.
Stepping back, IMO, this really has nothing to do with code or monorepos. Just don't introduce degrees of freedom when you don't need them.
FWIW - Pants totally aside, This is the same dance I do for Rust. Add a dep to Cargo.toml, refresh the IDE.
Or, if I'm lazier, I don't do that and just read the rustdoc well and type without assistance. That takes both laziness and a bit of bravery, but works. I only do it sometimes.
l
That's fair. I was asking in the context of monorepos because they would tend to have more dependencies. But if I understand your general point it is that you should have one venv and list of deps if you can get away with it. If you get into a situation where you have conflicting deps then you need to split them. But only split if you absolutely have to. This would apply to a monorepo or multi repo.
e
Yes, exactly.
As to requirements.txt or pyproject.toml, it totally depends. I use requirements.txt when I need interop with simple CLI tools. The toml gets in the way of that. If I don't have that constraint and I actually publish the project, then maybe pyproject.toml, but really only if I need to publish it.
If it can't be cut / grep / sed'ed its not too useful and usually in the way!
l
Fair. I lean towards pyproject.toml because it gives me one place to define other configs like linting tools, so I don't have half a dozen .configsomething. But your point is good
e
Yeah, for those it tends to work since I have not found many needs for glue tooling. Black does its thing, no other tool cares, etc. Requirements are a different story though. ~Everybody cares about those.
If there were a jq for toml, that would also be a different story.
l
Either way it gives me some good stuff to think about. Thanks!
p
Open in Slack
PreviousNext
Powered by