Refactor IsolatedEnv, take two
#537
Conversation
layday
force-pushed
the
delegate-scripts-dir-to-isolated-env
branch
3 times, most recently
from
5e93049
to
827ac96
Compare
henryiii
force-pushed
the
delegate-scripts-dir-to-isolated-env
branch
from
827ac96
to
b345170
Compare
layday
force-pushed
the
delegate-scripts-dir-to-isolated-env
branch
2 times, most recently
from
e896a14
to
2c26411
Compare
|
Is there something I can do to push this forward? |
|
Just need to push a release, then this can be reviewed and merged. (Technically can be reviewed anytime, but at least I'm likely busy till after a release). |
| FailedProcessError, | ||
| TypoWarning, | ||
| ) | ||
| from ._util import check_dependency, parse_wheel_filename |
There was a problem hiding this comment.
We already have a util, also having a _util seems confusing? If it's important to hide these, they could be _check_dependency and _parse_wheel_filename in util? Or maybe they could be in a file with a better private name?
Having public and private utils separated in this way isn't terrible though, just checking.
There was a problem hiding this comment.
Suppose we could call it _helpers. If we underscore the functions themselves we can't import them without it being flagged as an error by Mypy and Pyright.
There was a problem hiding this comment.
Yes they can, we just need __all__ (which we should be adding anyway, along with __dir__).
There was a problem hiding this comment.
But that would make them public assuming they are contained in a public (i.e. ununderscored) module. check_dependency is already public of course but parse_wheel_filename is private.
There was a problem hiding this comment.
I'd say that an underscored name in a __all__ is still hidden, it just means it is used from other modules. Using it downstream is just as risky as if there was no __all__. __all__ describes what is used by other modules - things not in __all__ should only be used in the file they reside in.
You could even filter things that start with an underscore in __dir__, but I'd not bother, things like IDEs and IPython still filter them by default.
There was a problem hiding this comment.
Are they also hidden from Sphinx?
There was a problem hiding this comment.
I think having a private module for internal use is cleaner FWIW, but I don't feel strongly about this.
There was a problem hiding this comment.
I'm fine with it either way. Just a note.
Sphinx hides things starting with an underscore by default, but it's configurable, IIRC.
There was a problem hiding this comment.
@gaborbernat or @FFY00, could we get one more pair of eyes? If we don't hear anything, let's merge Jan 25.
- `install` is not required to interface with the backend -- consumers can provision the isolated env in whichever manner they see fit. - Assume responsibility for mutating `os.environ` -- different isolated envs may need to modify different env vars. As a consequence, the `scripts_dir` does not need to be exposed to the `ProjectBuilder`.
Reorganised the `ProjectBuilder` to accommodate the new constructor. `scripts_dir` was removed and mutating the `python_executable` is not supported anymore. `srcdir` was renamed to `source_dir` to parallel the hooks' `*_dir` params.
layday
force-pushed
the
delegate-scripts-dir-to-isolated-env
branch
from
c741c1c
to
28c95a7
Compare
This is a more modest set of changes than I had in #361. Changing the runner's signature to make removing variables from the environ possible can come in a follow-up PR. Just as #361, this removes the env builder, redefines the isolated env interface, and adds an isolated env constructor to the project builder.