fix: enhance error handling for path supported manifests

[ruben-arts]

Description

Fixes prefix-dev/pixi-build-backends#515

Now it errors with:

  × the source directory '<CARGO_ROOT>/tests/data/discovery/ros-package', does not contain a supported manifest
  help: ROS packages require you to specify the 'package.xml' file path directly, due to supporting more backends in the future. Or ensure that the source directory contains a valid manifest file:
        pixi.toml, pyproject.toml, mojoproject.toml, recipe.yaml, recipe.yml.

Pretty verbose but hopefuly it helps the user.

AI Disclosure

• This PR contains AI-generated content.
  • I have tested any AI-generated content in my PR.
  • I take responsibility for any AI-generated content in my PR.

Tools: Claude

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas

[baszalmstra]

What would be the downside of not erroring out but just detecting the package.xml and running with it? This type of error is one where Im always like, "yeah duh, just do that yourself".

[nichmor]

What would be the downside of not erroring out but just detecting the package.xml and running with it? This type of error is one where Im always like, "yeah duh, just do that yourself".

yeah - sounds more user friendly. On the other hand, if there is both package.xml or pixi.toml then we error out

[baszalmstra]

Yeah that makes sense, if it's ambigous we should error.

[EzraBrooks]

I agree that making a best guess but erroring in the ambiguous case is a good idea. If there's multiple manifests there should be a specialized error message explaining the ambiguity imo.

[ruben-arts]

We actually reverted that right before we merged the package.xml feature. This was mostly due to the issue we'll create for ourselves, where the questions is when do we add the automated support and when do we avoid it. e.g. why wouldn't a cargo.toml, CMakeLists.txt and package.json be picked up?

We need to keep a baked in map that maps manifests to backends which is just a complex maintainence issue.

There is still the plan to not autodetect any format other than real pixi manifests (pixi.toml, pyproject.toml) and allow users to specify the backend they want to use.
e.g.:

ros-package = { path = "pkg", backend = "pixi-build-ros==1.2.3"}

My robotics "just make it work" brain hates me for this, but the Pixi maintainer brain is pretty anxious about the maintainence and breaking changes.

What do you think @baszalmstra.

[baszalmstra]

I see your point but we currently do already "soft support" this if you point it directly to a package.xml. With this error message we also explicitly mention that we detected the package.xml but we want the user to be more explicit about using it.

If this is just a stop-gap solution which we will remove later in favor of your example:

ros-package = { path = "pkg", backend = "pixi-build-ros==1.2.3"}

then I would either also just support pointing to a parent directory, or modify the error to indicate its a stop-gap solution or be explicit about why the user has to be explicit about this.

I can see the issue where conda-forge doesnt yet contain the ros-backend though, maybe we should just start adding it there?

[ruben-arts]

I've changed it to be more explicit in the error, why it should change. I was playing with adding the package.xml in dir discovery but it opens a can of worms we're going to replace anyway.