feat: pixi exec --list

[lucascolley]

Problem description

Pasting from discussion on discord with @Hofer-Julian. I have a branch at lucascolley@fe54efb which has started looking at this—currently need to figure out how to pass the installed environment to list::execute.

---

Suppose a user reports a bug with scikit-learn version x.y.z, and I fail to reproduce with pixi exec -s scikit-learn=x.y.z .... We might suspect that the bug depends on certain versions of numpy or scipy, so I'd like to quickly share my versions and ask the user for theirs.

pixi exec --list wouldn't make a huge difference when it is just one or two dependencies we are interested in like this, but it becomes a lot faster the more dependencies you are interested in. And useful when we are not sure which dependencies might make a difference. Some packages have included things like import sklearn; sklearn.show_versions() to make this easier from the Python side, but this won't be available for all packages (and is still slower).

pixi exec --list -s scikit-learn=x.y.z -s ipython ipython would:

• create and install the environment matching the given specs as usual
• (new) give the output of pixi list as if we had instead gone through the more involved process of pixi init && pixi add scikit-learn=x.y.z ipython && pixi list
• then run ipython in the environment as usual

My main motivation is to avoid having to pixi init a new project every time I want to do something like this. A caveat here is that we don't support the various optional arguments to pixi list unless we add them to exec as well, but I would be happy with just the default pixi list output.

Similarly, pixi exec --list numpy -s ... could work also.

[lucascolley]

I looked into this a bit further. It seems like pixi list requires an environment with a lock file, but pixi exec does not currently generate a lock file (or an Environment). Is that right?

[Hofer-Julian]

I looked into this a bit further. It seems like pixi list requires an environment with a lock file, but pixi exec does not currently generate a lock file (or an Environment). Is that right?

Probably better to share (or copy) functionality with pixi global list then

[lucascolley]

thanks for the pointer! I think I basically need to figure out how to go from

pixi/src/cli/exec.rs

Lines 181 to 189 in 31ce561

	let solved_records = wrap_in_progress("solving environment", move || {
	Solver.solve(SolverTask {
	specs,
	virtual_packages,
	..SolverTask::from_iter(&repodata)
	})
	})
	.into_diagnostic()
	.context("failed to solve environment")?;

to a Vec<PackageToOutput>:

pixi/src/global/list.rs

Lines 373 to 379 in 31ce561

	struct PackageToOutput {
	name: PackageName,
	version: Version,
	build: Option<String>,
	size_bytes: Option<u64>,
	is_explicit: bool,
	}

pixi global list gets this via global::project::parsed_manifest::ParsedEnvironment

pixi/src/global/list.rs

Lines 160 to 170 in 31ce561

	let mut packages_to_output: Vec<PackageToOutput> = records
	.iter()
	.map(|record| {
	PackageToOutput::new(
	&record.repodata_record.package_record,
	env.dependencies
	.specs
	.contains_key(&record.repodata_record.package_record.name),
	)
	})
	.collect();

where we are getting at specs: IndexMap<rattler_conda_types::PackageName, PixiSpec>.

Any pointers on how we can acquire/create these PixiSpec maps without a global manifest? Or is using this machinery from pixi global list barking up the wrong tree?

[lucascolley]

Actually, after looking with a fresh pair of eyes, I think we're accessing those specs to determine which dependencies are explicit. We should have that information already available in exec.