python virtualenv_default_packages in rtx.toml

[dsully]

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]

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

[jdx]

meanwhile you can use this instead

[dsully]

@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]

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]

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]

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]

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.