prefix-dev/pixi

Problem description When using non-trivial environments, I resort to comment for describing the environments [environments] # environment for integration tests using a development server test-integration = { features = ["test", "dev-server"] } It would be nice, if environments would gain a field description, similar to tasks. A field is a bit better integrated than just a comment and e.g. pixi info could show the description for the environments, which would be a usability gain because then we not only see what the environment is, but a description could convey why it exists / its purpose. I would like to be able to do [environments] test-integration = { features = ["test", "dev-server"], description = "environment for integration tests using a development server" } while this is a little less readable than the comment, that will be fixed with the yet unreleased TOML v1.1 spec, because then one could also write [environments] test-integration = { description = "environment for integr

Problem description The docs suggest that you can use an arbitrary name for the .toml file provided to --manifest-path: You can combine working-directory with manifest-path if needed: - uses: prefix-dev/[email protected] with: working-directory: ./packages/my-project manifest-path: custom-pixi.toml However this doesn't appear to be true. The only acceptable parameters for --manifest-path are: path to pixi.toml path to pyproject.toml path to a directory that contains either pixi.toml or python.toml In any case, it would be very useful for complex testing and CI/CD situations to be able to specify a file named something other than "pixi.toml" in the project root or an arbitrary path. For example: - myproject - src/myproject - (source code etc.) - pixi.lock - pixi.toml - pixi-ci.lock - pixi-ci.toml - pyproject.toml - tests/ - test_myproject.py - pixi-tests.lock - pixi-tests.toml Running pixi lock at the project roo

Problem description Hello everyone, I'm opening this issue as a placeholder to consolidate discussions related to VS Code support. Despite earlier efforts to streamline integration, the recent shift to the new Environment Managers has reintroduced a dependency on third-party extensions. The current documentation outlines the required setup steps, but the overall user experience remains suboptimal. For broader industry adoption, a more robust and reliable solution is needed. Relying on community-maintained extensions is challenging, as they cannot always keep pace with upstream changes in VS Code or respond quickly to bugs or opened PRs. Is there any plan to develop an official extension that provides full autodetection, as well as integrated run, debug, and pytest support? A seamless, officially maintained experience would significantly strengthen confidence in adopting Pixi across larger projects and ecosystems. Without it, there is a risk that teams may look toward alternative or cus

Problem description When using uv, if I do uv lock and uv sync in a project with pyproject.toml, the if there is a dev dependency-group, the listed packages are automatically added to the default environment. With pixi however, they get added to the dev environment only. It would be nice to be able to specify that the special dev dependency group should be part of the default environment, since typically for libraries lockfiles get added for reproducible dev environments, not just for runtime dependencies. I also use pixi to do matrixed python version testing, with py31* features. The associated envs need these features + dev to get all the packages needed to run tests etc, but then if I add any tasks to the dev feature then I get asked which environment I would want to use every time. I could of course specify the environment at the CLI, but I'd rather avoid needing to do this. What I'd like to do is to always run the tasks in the default environment (like say a linting task), but the

Problem description repodata-config.disable-jlap was recently removed from the config struct. This resulted in a warning about that value not existing. That's all fine but you should be able to use pixi config unset to remove unknown values from that config. E.g.: this should work IMO pixi config unset repodata-config.disable-jlap It would be best if you can use the pixi config unset to remove any type of TOML value from the config files. Also because our warnings contain the exact config file path it would be great if pixi config could accept paths to those files to eliminate issues where the user doesn't know which config level e.g. --global --local etc.