Another stupid question as I didn’t find anything ...
# general
s
Another stupid question as I didn’t find anything related inside the documentation. Coming from a JavaScript background, I was used to having what we call “development dependencies” (living in
requirements-dev.txt
) and actual dependencies (living in
requirements.txt
). Do I understand correctly, that with Pants we don’t need that Schema anymore, since the BUILD or the dependency inference will package all needed dependencies within the PEX-File? What is odd in the phase of migration right now is that
tailor
is generating a conflicting
python_requirements()
inside the
src/BUILD
file right now. I understand from the documentation that I can make
tailor
ignore the generation using
ignore_adding_targets
, but is that really what I need to do in my situation? Right now after running
./pants tailor
and linting with
./pants lint ::
I get the following error message:
Copy code
❯ ./pants lint ::
19:19:05.32 [ERROR] 1 Exception encountered:

  DuplicateNameError: A target already exists at 'src/BUILD' with name 'pytest' and target type 'python_requirement'. The 'python_requirement' target cannot use the same name.
So here’s the stupid question? Can I give the python_requirement target a name? The documentation has no field about this. 🙂
c
Yes, you can. All targets are named, and must be uniquely so. Only if the name field is left out it defaults to the name of the residing directory.
Btw, there's no stupid questions here ;)
💯 2
☝️ 2
And yes, dep inference ensures you don't end up with dev deps in your production code.
s
Thanks for getting back to me that quick! I guess learning a completely new (and awesome) concept for Python just feels uncomfortable for me. The biggest concern for me right now is the adoption of Pants without changing too much of our codebase. I don‘t know if that‘s even possible because I‘m stepping in the dark a lot of times. Anyways 😅, thanks again for clarifying! I will proceed and come back with more questions. I will also add another suggestion to the inc. adoption page.
@curved-television-6568 how would I add a name to a
python_requirements()
target?
c
python_requirements(name=“..”)
ought to work..
s
This results in an error. Here’s the BUILD contents:
Copy code
pex_binary(
    name="manage",
    entry_point="manage.py",
    restartable=True,
)

python_requirements(
    name="dev-requirements",
    source="requirements-dev.txt",
)

python_sources()

python_requirements()

python_test_utils(
    name="test_utils",
)
Here’s the error:
Copy code
❯ ./pants lint ::
19:42:44.50 [ERROR] 1 Exception encountered:

  MappingError: Failed to parse ./src/BUILD:
__call__() got an unexpected keyword argument 'name'
c
We're suffering from “the curse of knowledge” as Eric would point out, not having explained this clearly enough in the documentation.
s
Ah wait, I missed the name 🙈 give me a second.
⏲️ 1
Fixed the example above.
c
Oh, hmmm… ok, first what version of pants are you using?
s
Copy code
[GLOBAL]
pants_version = "2.9.0"
c
I’ll have to look this up. (On the phone now…)
s
Here is the documentation about the
python_requirement
command. An immediate answer is not necessary at all 😄 I was just tinkering around with this and could finally clarify what I’d like to ask.
c
Ah, right. 2.9 is still using the now deprecated CAOF (Context Aware Object Factory) macro for
python_requirements
, which does indeed not take a name as argument. In 2.10, it’s replaced by a target generator, that works more like regular targets.
But I don’t think the COAF macro is the issue here, but that you have
pytest
in both requirements.txt files, by the looks of it.. ?
So one way to work around that, if possible, is to either a) avoid duplicate entries between the two files, or b) move the files so they’re not in the same directory, giving the
python_requirment
targets unique addresses. I’m not entirely sure how well it would work with the same 3rdparty requirement several times, though…
in 2.11, there’ll be initial support for multiple lockfiles to address this use case.
s
Uh, that’s true! I’ll have to dig in a little to see why 🤔
Is 2.10 / 2.11 released yet? Would you suggest for us to start with 2.11 right away?
c
There’s a rc for 2.10 out, closing in to become stable.
If you need multiple lockfiles, and are aware of the caveats for the still unresolved known issues with it, trying out 2.11 could be viable I think.
s
Removing
pytest
from the
requirements.txt
completely resolves my issue. Another mistake on my end 🙈
Thanks a lot for helping me! I really appreciate it ❤️
👍 1
c
happy to help 🙂
btw, regarding 2.11 and multiple resolves, I think this is the best information I could find in the docs, so far: https://www.pantsbuild.org/v2.11/docs/reference-python#section-enable-resolves @hundreds-father-404 will fill us in if I missed something here 😉
👀 1
b
It's good to point out too, with Pants, tools that can run in their own environment will. Which is a step better then dev dependencies. An example being if two dev tools conflict on a version
poetry
can't solve that but Pants can.
👍 1
🙌 1
Tools that can't (like
pylint
or
mypy
or
pytest
) are still subjected to this issue, but that's how it goes 🙂
c
life's like a box of chocolate
🍤 1
h
Thanks Andreas and Joshua for pitching in! Hey @strong-toothbrush-37759 sorry I missed the ping. This use case is a very important reason why we fixed in Pants 2.10 to stop using the old macro mechanism in favor of "target generator". In Pants 2.9, you can't have two
python_requirements
in the same directory where they both have the same target 😵 That is fixed with Pants 2.10 Also launching in Pants 2.10 (not 2.11) is "multiple resolves", aka multiple lockfiles. https://www.pantsbuild.org/v2.10/docs/python-third-party-dependencies#lockfiles Where are you currently at with getting the above to work?
👍 1
🙌 1
s
@hundreds-father-404 thanks for coming back to me, this was just a mistake where
pytest
and some other libs were accidentally written into
requirements.txt
as well as the
requirements-dev.txt
. I fixed it by just removing the duplication.
💯 1