https://pantsbuild.org/ logo
Join Slack
Powered by
<@U06A03HV1> / <@U021C96KUGJ>: Any thoughts on the...
# development
f
@witty-crayon-22786 / @ancient-vegetable-10556: Any thoughts on the coursier bug described in https://github.com/pantsbuild/pants/issues/13496?
w
none
does it look hard to fix?
f
should be easy to fix upstream
the harder part is deciding whether we need to deploy our own build of coursier until they do a release upstream
w
that’s probably the path then… he’s been really helpful getting releases out
well, if we need to temporarily disable strict until then, that’s fine too. it’s not a blocker to have it on… just something i felt would be good to have in place before people are deploying at scale
f
okay, relaxing that requirement until we see a fix simplifies the issue then
w
@wide-energy-11069: any idea why Twitter never hit this one? see https://github.com/pantsbuild/pants/issues/13496
afaik, 
force=True
used this flag, right?
w
does it have anything do with leaving with the version constraints to be open? In twitter, all versions are fixed/pinned.
f
the issue is with the 
--strict-include
flag parsing
w
@fast-nail-55400: i only passed the 
$org:$name
portion, because i thought that that was what the flag wanted
f
yeah the issue is that the parser doesn’t like underscores
w
iirc it is what it wants, but i think that’s what @wide-energy-11069 is asking about
f
which of course blows up with 
_2.13
is a suffix
w
…can always look at the v1 code i guess
f
I’ll fix it upstream by allowing underscore.
w
(FWIW, twitter also never used this flag 
--strict-include
)
w
mm, yea: got it. looks like 
force=True
used 
-V
…?
f
seems not relevant. the issue is with the coursier strict resolver and the --strict-include flag which Pants v1 doesn’t use.
w
Copy code
--force-version | -V  <organization:name:forcedVersion>
        Force module version
so what is the difference between forced and strict then… hm.
f
🤷
w
…oh. 
-V
just says: “definitely use this one, even if it’s not compatible.”
i.e., the example in the 
strict
ticket passes, and you just get exactly that version.
which … would work, but semantically doesn’t do as much anything to help you out if you’ve pinned to something incompatible
@fast-nail-55400: so yea, i think that helping out to fix 
strict
would make sense. because i think that it makes a good default
…in fact. wait a sec. can we just enable it globally instead, rather than poking only the deps we want to be strict?
f
It still gave me an error when I used 
--strict
w
oh… it parses them internally?
f
yup
w
k.
f
it has a meta-language (because of course it does) for describing the constraints and it parses them …
w
i think that the path forward is still to fix parsing for 
strict
and disable it in the meantime.
in the future we may need to expose 
-V
for “i know this isn’t compatible, but use it anyway”, but not right now.
f
i think that the path forward is still to fix parsing for 
strict
 and disable it in the meantime.
agreed
w
@wide-energy-11069: thanks! hope you’re doing well.
w
np. thanks! you too!
Open in Slack
PreviousNext
Powered by