-
-
Notifications
You must be signed in to change notification settings - Fork 646
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
javascript: NodeJS bootstrapping via binary paths, PATH, asdf or nvm #18520
Conversation
Either on PATH or via asdf installations.
def __init__(self, *args, **kwargs): | ||
super().__init__(*args, **kwargs) | ||
self.check_version_constraints() | ||
class ExternalToolOptionsMixin: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't find much precedence for this kind of code reuse, but I'm not sure how else to fit the square "downloaded external tool" peg into the bootstrapping round hole, as the interfaces for TemplatedExternalTool
just doesn't fit semver
versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with it. @thejcannon : you recently had to emulate ExternalTool
without actually implementing it: is there any connection to what @tobni is doing here?
@@ -38,6 +38,7 @@ types-setuptools==62.6.1 | |||
types-toml==0.10.8 | |||
typing-extensions==4.3.0 | |||
mypy-typing-asserts==0.1.1 | |||
node-semver==0.9.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I asked about this in slack https://pantsbuild.slack.com/archives/C0D7TNJHL/p1678052689358149
This option take precedence over the templated url download, | ||
if a version matching the configured version range is found | ||
in these paths. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes it less hermetic(I think?), but also what I think is most intuitive to users? I'm guessing here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, interesting. And the advantage to doing this is that it avoids the download? That's probably not necessary on an end user machine, but could make sense in CI. But in CI you could also imagine that somebody would be fine explicitly enabling a local search path (rather than having it on by default) for node as an optimization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And the advantage to doing this is that it avoids the download?
Indeed. That, and a little bit of consistency across backend, what with go
and python
backends both defaulting to search_paths to find their runtimes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That, and a little bit of consistency across backend, what with
go
andpython
backends both defaulting to search_paths to find their runtimes.
While true, that has caused us no end of issues, heh. Hermetic by default would be quite nice: it's what we have for the java
/scala
backends.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Flipping the switch is simple, so I'll do it!
test=BinaryPathTest( | ||
["--version"], fingerprint_stdout=False | ||
), # Hack to retain version info |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this too hacky? I'm annoyed by the prospect to have to iterate the paths again to call the node --version
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that it seems fine? AFAICT, fingerprint_stdout
exists for cases where the output might be large.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More the name of the variable that gave me pause, I think. It's called "fingerprint" but is the --version
output. Fingerprint usually makes me think "hash".
@@ -133,6 +142,8 @@ class EnvironmentAware(Subsystem.EnvironmentAware): | |||
|
|||
* `{AsdfPathString.STANDARD}`, {AsdfPathString.STANDARD.description("Node.js")} | |||
* `{AsdfPathString.LOCAL}`, {AsdfPathString.LOCAL.description("binaries")} | |||
* `<NVM>`, all NodeJS versions under $NVM_DIR/versions/node | |||
* `<NVM_LOCAL>`, the nvm installation with the version in BUILD_ROOT/.nvmrc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should it be possible to defer the version option to this file as well? Repeating the version in both pants.toml
and .nvmrc
(or .node-version
, for that matter) seem like bad UX.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should it be possible to defer the version option to this file as well?
Do you mean "infer"? Right now I don't think that it would be possible, because ExternalTool
has the version as a class member.
Second best though would be to validate that both copies of the version are equal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, infer. I think I'll leave this as is for now if that's alright, validating the contents should probably happen in all backends with asdf support for example, and I think that work is a larger tangle.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot!
This option take precedence over the templated url download, | ||
if a version matching the configured version range is found | ||
in these paths. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, interesting. And the advantage to doing this is that it avoids the download? That's probably not necessary on an end user machine, but could make sense in CI. But in CI you could also imagine that somebody would be fine explicitly enabling a local search path (rather than having it on by default) for node as an optimization.
@@ -133,6 +142,8 @@ class EnvironmentAware(Subsystem.EnvironmentAware): | |||
|
|||
* `{AsdfPathString.STANDARD}`, {AsdfPathString.STANDARD.description("Node.js")} | |||
* `{AsdfPathString.LOCAL}`, {AsdfPathString.LOCAL.description("binaries")} | |||
* `<NVM>`, all NodeJS versions under $NVM_DIR/versions/node | |||
* `<NVM_LOCAL>`, the nvm installation with the version in BUILD_ROOT/.nvmrc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should it be possible to defer the version option to this file as well?
Do you mean "infer"? Right now I don't think that it would be possible, because ExternalTool
has the version as a class member.
Second best though would be to validate that both copies of the version are equal.
test=BinaryPathTest( | ||
["--version"], fingerprint_stdout=False | ||
), # Hack to retain version info |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that it seems fine? AFAICT, fingerprint_stdout
exists for cases where the output might be large.
def __init__(self, *args, **kwargs): | ||
super().__init__(*args, **kwargs) | ||
self.check_version_constraints() | ||
class ExternalToolOptionsMixin: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with it. @thejcannon : you recently had to emulate ExternalTool
without actually implementing it: is there any connection to what @tobni is doing here?
Enables (nodejs dialect) semver version specification for NodeJs binary in the
nodejs
subsystem.Also enables support for
asdf
andnvm
binary installation discovery, along with$PATH
discovery.Addresses #16959.