Hi everyone! I'm struggling with pants requirement...
# general
c
Hi everyone! I'm struggling with pants requirements while building multiple targets that have disjoint dependencies. Do anyone know solution to handle this?
Copy code
Exception message: Could not satisfy all requirements for Markdown==2.1.1:
    Markdown==2.1.1(from: pantsbuild.pants==1.23.0), markdown>=2.6.8(from: tensorflow==1.12.0->tensorboard<1.13.0,>=1.12.0)
I'm out of ideas
i can build them separately in a loop, but it is not desired solution
h
Let me see
OK so wider problem is that Pants shouldn't be so restrictive in its version of Markdown (in fact, it probably shouldn't depend on Markdown at all unless you're using the docgen backend).
👍 1
Quick question: Your code depends on pantsbuild.pants as a library?
Is that because you have custom pants tasks or something?
c
yes, i use it in
docker-plugin
to build images with
.pex
Copy code
python_library(
    name = "docker",
    dependencies = [
        "3rdparty/python:pantsbuild.pants",
    ],
    sources = globs("*.py"),
)
I would like to know a generic way how to deal with such conflicts. Isn't there a special
TAG
for that case?
h
@hundreds-father-404 What do we do in these cases to re-pin a dep that for some reason Pants is insisting on a specific version of?
@chilly-carpet-91912 What is the pants command you're running?
c
.pants bundle
h
What do we do in these cases to re-pin a dep that for some reason Pants is insisting on a specific version of?
I don’t think there’s any solution for this, afaict. Generally, Pants is likely far too restrictive in its version numbers and this was a huge pain point when I was at Foursquare to make sure that versions matched
☹️ 1
While it doesn’t solve the problem immediately, @chilly-carpet-91912 you could put up a PR to update Pants’ markdown dependency to something more modern - possibly make it no longer be pinned - and that would go out in the new dev release next week
c
That sounds reasonable
@hundreds-father-404 post an issue? Or make a PR?
h
If you’re willing, making a PR would be great! This would mean researching Markdown’s changelog to find a reasonable version for us to pin/float to, then changing
3rdparyt/python/requirements.txt
. See https://www.pantsbuild.org/howto_contribute.html for a contributor guide
👍 1
h
I wouldn't pin it at all, just let it float from some reasonable old version and up
c
how would You do that?
h
e.g.
Markdown>=2.1.1
c
yeah but it will install just the newest one
h
Yes, but will allow Pip to resolve older versions if other libraries have conflicting versions. If Pants allows for
>=2.1
and your other library requires
==2.2
, then Pip will resolve
2.2
, even if there is a newer version
2.3
c
thanks, sorry for question 😉
but when it does not find any restrictions (in other libraries) it can cause problems, but then it can be resolved manually by adding pinned dependency
h
but when it does not find any restrictions
Hence why we generally pin requirements in Pants. Usually, Pants is run as an executable. But it can also be used as a library. Executables want to pin their versions exactly to avoid things changing overnight on you and breaking the app. In contrast, libraries are better to float so that you don’t force a user to use a particular version of a library You’re correct that if you don’t like using the newest version of Markdown, in your own personal requirements.txt you could always pin to a specific version, so long as it’s compatible with all the other requirements
c
so adding
Markdown>=2.1.1
can't be done i guess
maybe we can add some option to handle it
i will think and when i find out sth will post in channel then
thanks for your time guys!
h
so adding Markdown>=2.1.1 can’t be done i guess
How come? I don’t follow
c
to not break anything
Usually, Pants is run as an executable. But it can also be used as a library. Executables want to pin their versions exactly to avoid things changing overnight on you and breaking the app.
@hundreds-father-404 isn't is potentially harmful for your users to update the requirements.txt with
Markdown>=2.1.1
h
So long as Markdown didn’t make any major changes, it should be fine. Which is why we need to audit the changelog for Markdown, rather than blindly updating to the newest version
c
i'll investigate