jdx / mise

dev tools, env vars, task runner
https://mise.jdx.dev
MIT License
9.86k stars 281 forks source link

python virtualenv_default_packages in rtx.toml #323

Open dsully opened 1 year ago

dsully commented 1 year ago

Describe the bug I created a .rtx.toml file using the example given in the top level README.md:

[tools]
python = { version = '3.10', virtualenv = '.venv', virtualenv_default_packages = [
    'jedi',
    'wheel',
] }

When I change to that directory, the following error is emitted:

Error:
   0: error parsing: /Users/dsully/dev/.../.rtx.toml expected value of "tools.python.default_packages" to be a string, got:  [
          'jedi',
          'wheel',
      ]

Location:
   src/config/mod.rs:403

Version:
   1.23.5 macos-arm64 (built 2023-03-13)

Expected behavior The given packages would install with no error. :)

rtx doctor output

$ rtx doctor
rtx version:
  1.23.5 macos-arm64 (built 2023-03-13)

shell:
  /opt/homebrew/bin/fish
  fish, version 3.6.0

rtx environment variables:
  RTX_USE_TOML=1
  RTX_TOOL_OPTS__VENV=.venv
  RTX_SHELL=fish
  RTX_EXPERIMENTAL=1

settings:
  {"experimental": "true", "missing_runtime_behavior": "prompt", "always_keep_download": "false", "legacy_version_file": "true", "plugin_autoupdate_last_check_duration": "10080", "verbose": "false", "asdf_compat": "false", "jobs": "4", "disable_default_shorthands": "false", "log_level": "INFO", "raw": "false"}

config files:

plugins:
  python   https://github.com/jdxcode/rtx-python.git#5853786

toolset:

No problems found
jdx commented 1 year ago

oh whoops, I documented this but forgot to actually implement it :)

jdx commented 1 year ago

meanwhile you can use this instead

dsully commented 1 year ago

@jdxcode I tried that already, but the behavior isn't what I expected. That only works when rtx global python@... is run, not when I enter a path with a .rtx.toml

Even when rtx global is run, those packages aren't (rightfully) exposed in that local virtualenv.

jdx commented 1 year ago

I see. In asdf this also only works when installing a python version, but I see how me putting this into .rtx.toml implies that different projects can install different packages, which is probably especially useful with virtualenvs.

I can probably do this detection whenever hook-env runs (anytime the prompt is shown), but I'm wondering if it's a mistake to offer this since it appears to be going a lot further than I anticipated. (are people going to want autoinstalling poetry/pipenv/npm packages next? how far does this rabbit hole go?) On the other hand, maybe that means it's just more useful than I originally thought?

This is still experimental so I'll probably add the ability to install on hook-env, but I am definitely unsure if this was a good idea or not.

jdx commented 1 year ago

I suppose another way to phrase what I'm saying is: should it actually be installing from requirements.txt? And if so, is it a good idea for rtx to start dabbling into dependencies instead of just runtime management?

dsully commented 1 year ago

I'm not sure - here's my use case: I want to install jedi and a few others developer tools for any virtualenv that I need to work in, which may or may not be a repository that I'm a contributor to.

Having that hook available in rtx would allow for that instead of a manual step.

At any rate, the current default packages functionality at the global config level doesn't make any sense, as it only applies to the install, not the local virtualenv.

jdx commented 11 months ago

after working with this a few months, I'm thinking tool options like this generally should not be things that modify install behavior since it only works when something is first installed. These are things that instead might make more sense as settings which are more thought of as user configuration.

I think virtualenv makes sense as a tool option because it modifies the behavior of environment variables when using an existing install. So I think what we could do is name this virtualenv_default_packages instead. Then it won't modify that global install. I changed your initial post to reflect that new name.