feat: make binary, config folder, and lock file names dynamic #2775
Conversation
|
Upstreaming some of the changes in magic to pixi. Some of the completion code and tests with insta made need to be tweaked. |
There was a problem hiding this comment.
Thanks, @zbowling, pretty excited to see magic moving closer to pixi.
I left a few comments and questions, please let me know if some of them are unclear to you.
src/cli/snapshots/pixi__cli__completion__tests__nushell_completion.snap
Outdated
Show resolved
Hide resolved
Happy Holidays! Yeah! Outside of some extra implicit default channels, some implicit auth from our install script token (that goes with our opt-in user telemetry), and a few extra connivence commands I've managed to reduce our patchset in pixi itself pretty dramatically to make it easier to track upstream changes quickly as they rollout (finding clever ways overloading things). Magic is basically moving to be a closer pure superset of pixi from the first release which forked a lot more. We still have the patches that add monoproject.toml as another project toml supported which is almost a pure superset of pixi.toml itself today but works with our tools in MAX implicitly (using an new file name to reserve the right to deviate since we have other tools that depend on it being similar to today but much of that could exist in pixi.toml or pyproject.toml in a section for our other tools but we read values from project section). That file in a project also triggers some hinting for things like our vscode extension so it knows the venv is managed by magic and not pixi, and that hints that the mojo lsp is likely available in venv. I'm not sure if pixi upstream wants those patches yet as mojoproject.toml hasn't proliferated too widely yet but it would be nice if pixi could just work with those projects out of the box even if you don't have our additional AI workflow helper commands in magic that work with MAX tools in venv (you don't need our helper commands because they can be invoked manually with tools in the MAX package if you want juggle things on your own). Some of those extra commands we added are AI workflow specific that assume MAX is in the project (like how a python package is required to use pypi deps today in the toml) but some commands are general purpose enough and not AI dev specific to maybe go into pixi eventually but incubating in magic to fully flush them that I want to upstream. One feature still in development is "magic create" that is a "pixi init" alternative for lot of uses cases especially where you are not converting an existing codebase or want minimal generation which pixi init is still useful but starting a new fully flushed project from scratch using a scaffold generator. It uses a pluggable driver package in conda to assist with project scaffold generation. This is very much like "npm init" works with "create-" packages as generators. This interestingly is similar to how pixi build backends work and that feature compliments that function pretty well. It allows for interactive generation too, so for example you can ask the user what python build backend they want, what version of python they want, if they want a flat style or src dir style project, what python test framework they wants, etc - almost like how "pdm init" asks you when generating. |
zbowling
force-pushed
the
zbowling/pixi-dir
branch
from
7bb232c to
a79213f
Compare
| lazy_static! { | ||
| /// The default channels to use for a new project. | ||
| pub static ref DEFAULT_CHANNELS: Vec<NamedChannelOrUrl> = match option_env!("PIXI_DEFAULT_CHANNELS") { | ||
| Some(channels) => channels.split(',').map(|s| NamedChannelOrUrl::from_str(s).expect("unable to parse default channel")).collect(), |
There was a problem hiding this comment.
There is a super small potential for a bug in that , can exist inside a URL, but I don't think it's typical and didn't want to do something complicated for string escaping. Since this is embedded into the executable I would hope someone who statically set a URL with a , in it would catch it before shipping a binary since basically everything will be broken.
There was a problem hiding this comment.
Okay, will add a comment in a follow up PR
Make the pixi binary name dynamic so that it's determined off the actual binary name when invoked so if it's renamed, it reports correctly. Make the pixi config folder and default lock file to use overridable in cargo config. Make the default channels overriable in a build in cargo config. Automatically parse full URLs in default channels list as URLs and not short names at compile time. Make some functions and mods accessed externally pub instead of pub(crate).
Co-authored-by: Hofer-Julian <[email protected]>
Co-authored-by: Hofer-Julian <[email protected]>
Co-authored-by: Hofer-Julian <[email protected]>
Co-authored-by: Hofer-Julian <[email protected]>
zbowling
force-pushed
the
zbowling/pixi-dir
branch
from
a79213f to
4c38f5e
Compare
|
There is an intermittent windows pytest flake. Rebased on main to see if it passes. |
|
@baszalmstra @Hofer-Julian this should be good. There is a windows python test flake |
| lazy_static! { | ||
| /// The default channels to use for a new project. | ||
| pub static ref DEFAULT_CHANNELS: Vec<NamedChannelOrUrl> = match option_env!("PIXI_DEFAULT_CHANNELS") { | ||
| Some(channels) => channels.split(',').map(|s| NamedChannelOrUrl::from_str(s).expect("unable to parse default channel")).collect(), |
There was a problem hiding this comment.
Okay, will add a comment in a follow up PR
Make the pixi binary name dynamic so that it's determined off the actual binary name when invoked so that if it's renamed, it reports correctly.
Make the pixi config folder and default lock file to use overridable in cargo config.
Make the default channels overridable in a built-in cargo config. Automatically parse full URLs in default channels list as URLs and not short names at compile time.
Make some functions and mods accessed externally pub instead of pub(crate).