I have a weird one. Using openapi-generator to cre...
# general
p
I have a weird one. Using openapi-generator to create a python library. Currently this happens in a Makefile. The created structure is... lib/ • lib/ • test/ • requirements.txt Adding the src root of lib.. then running tailor adds a BUILD file to lib, but it is picking up the requirements.txt.. which causes tests to fail. If I delete lib/BUILD then tests past.. So my question is. How can I specify the source root appropriately? Does it need to be lib/lib + lib/test ? For this stage of the migration I'd like to leave the make target responsible for generating the library.. then augment that with
pants tailor lib/ ::
. Unfortunately, there is a pile of custom to support this.
b
Does the
requirements.txt
not include dependencies for pants to use? There's some options like https://www.pantsbuild.org/docs/reference-python#tailor_requirements_targets that will stop
tailor
adding targets. Another option might be ensuring the file is owned by another target that's not
python_requirements
, e.g.
file(sources=["requirements.txt"])
. The second one is likely to be useful if you need to use the file from within pants, as a normal file (e.g. putting it in an archive or something).
p
Hmm.. So the requirements.txt looks fine to me. The lib/BUILD file ends up being
Copy code
python_sources()

python_requirements(
    name="reqs",
)

python_requirements(
    name="reqs0",
    source="test-requirements.txt",
)
Where lib/requirements.txt is generated as
Copy code
certifi >= 14.05.14
frozendict >= 2.0.3
python_dateutil >= 2.5.3
setuptools >= 21.0.0
urllib3 >= 1.15.1
Failures are..
Copy code
___________ ERROR collecting observatory_api/test/test_motor_api.py ____________
ImportError while importing test module '/tmp/pants-sandbox-KkdP79/observatory_api/test/test_motor_api.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/home/geethree/.pyenv/versions/3.9.10/lib/python3.9/importlib/__init__.py:127: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
observatory_api/test/test_motor_api.py:15: in <module>
    import observatory_api
observatory_api/observatory_api/__init__.py:18: in <module>
    from observatory_api.api_client import ApiClient
observatory_api/observatory_api/api_client.py:24: in <module>
    import urllib3
E   ModuleNotFoundError: No module named 'urllib3'
I do have urllib3 in my lockfile from my current requirements
To utilize
tailor_requirements_targets
.. I would need a negative lookahead to ignore lib/requirements.txt? hmmp
Ah forgot test-requirements.txt, which is
Copy code
pytest~=4.6.7 # needed for python 3.4
pytest-cov>=2.8.1
pytest-randomly==1.2.3 # needed for python 3.4
b
Hm, I think I'm very confused. Do you want pants to be loading and interpreting the dependencies in the
requirements.txt
?
p
At this point in time. No.
So something like
Copy code
requirements_targets = (?!lib)/.*requirements.*
Might work.
b
Okay, cool. So I think the two options listed above are good ones to try. I'm not sure what you mean by negative lookaround, though. I'd expect removing the BUILD file (to start from scratch), setting
tailor_requirements_targets = false
and then running
pants tailor ::
should have the good behaviour (not adding the
python_requirements
target)?
p
Ahhhh tailor_requirements_targets = false goes into the BUILD file?
b
Ah, yeah. Exactly. In the
[python]
section.
p
I was thinking pants.toml [tailor]
b
oops, sorry, not exactly: in
pants.toml
, but in the
[python]
section
(this will mean that future
python_requirements
targets won't be automatically created, but you can always manually create them. The second option of using a manual
files
target doesn't have that particular failing.)
p
So.. pants.toml
Copy code
[python]
tailor_requirements_targets = "(?!lib)/.*requirements.*"
?
No.. that wants a boolean
Oh just = false and then manually add through out the repository is what you mean perhaps?
b
tailor helps with adding new targets, if there's new files added. It doesn't touch existing targets
p
Indeed. That works.
So the recourse of this is... tailor won't add requirements if there are new source roots added.
I can live with that.
b
yeah. And, if you don't want to live with it, you can have manual
files
targets for these particular requirements.txt's.