pixi init --format pyproject && pixi shell fails

[zbowling]

Checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

➜  ~ mkdir test2
➜  ~ pixi init --format pyproject
✔ Created /Users/zbowling/pyproject.toml
➜  ~ pixi shell
  × error updating pypi prefix
  ├─▶ Failed to prepare distributions
  ├─▶ Failed to fetch wheel: zbowling @ file:///Users/zbowling
  ├─▶ Failed to build: `zbowling @ file:///Users/zbowling`
  ╰─▶ Build backend failed to build wheel through `build_editable()` with exit status: 1
      --- stdout:

      --- stderr:
      Traceback (most recent call last):
        File "<string>", line 11, in <module>
        File "/Users/zbowling/Library/Caches/rattler/cache/uv-cache/environments-v0/.tmpK5v58O/lib/python3.12/
      site-packages/hatchling/build.py", line 83, in build_editable
          return os.path.basename(next(builder.build(directory=wheel_directory, versions=['editable'])))
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/Users/zbowling/Library/Caches/rattler/cache/uv-cache/environments-v0/.tmpK5v58O/lib/python3.12/
      site-packages/hatchling/builders/plugin/interface.py", line 155, in build
          artifact = version_api[version](directory, **build_data)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/Users/zbowling/Library/Caches/rattler/cache/uv-cache/environments-v0/.tmpK5v58O/lib/python3.12/
      site-packages/hatchling/builders/wheel.py", line 494, in build_editable
          return self.build_editable_detection(directory, **build_data)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/Users/zbowling/Library/Caches/rattler/cache/uv-cache/environments-v0/.tmpK5v58O/lib/python3.12/
      site-packages/hatchling/builders/wheel.py", line 505, in build_editable_detection
          for included_file in self.recurse_selected_project_files():
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/Users/zbowling/Library/Caches/rattler/cache/uv-cache/environments-v0/.tmpK5v58O/lib/python3.12/
      site-packages/hatchling/builders/plugin/interface.py", line 180, in recurse_selected_project_files
          if self.config.only_include:
             ^^^^^^^^^^^^^^^^^^^^^^^^
        File "/Users/zbowling/Library/Caches/rattler/cache/uv-cache/environments-v0/.tmpK5v58O/lib/python3.12/
      site-packages/hatchling/builders/config.py", line 806, in only_include
          only_include = only_include_config.get('only-include', self.default_only_include()) or self.packages
                                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/Users/zbowling/Library/Caches/rattler/cache/uv-cache/environments-v0/.tmpK5v58O/lib/python3.12/
      site-packages/hatchling/builders/wheel.py", line 260, in default_only_include
          return self.default_file_selection_options.only_include
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/Users/zbowling/.pixi/envs/default/lib/python3.12/functools.py", line 993, in __get__
          val = self.func(instance)
                ^^^^^^^^^^^^^^^^^^^
        File "/Users/zbowling/Library/Caches/rattler/cache/uv-cache/environments-v0/.tmpK5v58O/lib/python3.12/
      site-packages/hatchling/builders/wheel.py", line 248, in default_file_selection_options
          raise ValueError(message)
      ValueError: Unable to determine which files to ship inside the wheel using the following heuristics:
      https://hatch.pypa.io/latest/plugins/builder/wheel/#default-file-selection

      The most likely cause of this is that there is no directory that matches the name of your project
      (zbowling).

      At least one file selection option must be defined in the `tool.hatch.build.targets.wheel` table, see:
      https://hatch.pypa.io/latest/config/build/

      As an example, if you intend to ship a directory named `foo` that resides within a `src` directory located
      at the root of your project, you can define the following:

      [tool.hatch.build.targets.wheel]
      packages = ["src/foo"]
      ---

Issue description

Hatchling is failing to compile the pyproject which is the default that init produces as a build backend now after a recent commit to swap setuptools to hatchling.build

Change the init to this gets it to work:
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"

Expected behavior

Should work.

[Hofer-Julian]

Hey @zbowling 👋🏻

To be honest, I wonder if what you see here is fine?

The error message is pretty clear and it also makes sense to me that if you have a pyproject.toml that there's also a corresponding python package.

[zbowling]

@Hofer-Julian The issue is you can't get into a shell to then use tools within the shell like python to help you generate the actual package since init doesn't generate a full package, just a pyproject.toml. Bit of a chicken and egg issue. Both pixi run and pixi shell shell fail immediately. This creates even more fun in vscode when you open the env in that folder. You get stuck in a loop.

Like if init is something like hatch new and it generates a src/, tests/, etc project with an empty init.py, then it would be fine. There would be enough. But you can't even pixi add --pypi hatch && pixi run hatch new.

setuptools doesn't bark or fail if you don't have any source files.

[Hofer-Julian]

Like if init something like hatch new and generated a src/, tests/, etc project with an empty init.py then it would be fine

I thought about it more and I agree with you. Let's adapt pixi init accordingly!

[zbowling]

I think we talking about adding a proper init template system at one point. there is a feature bug for that. Something like npm init so we can generate off scaffolds. that would help us down here downstream in mojo a ton :) but then we can have a hatch or poetry or pdm style init generation for different backends. long term bigger solution maybe.

[zbowling]

also build backend failures to install the current project by uv into the current env that can prevent a pixi shell and pixi run to execute is also a fun meta problem. You could be in the middle of working on your code, and if your code doesn't work right, then your shell might not start but then you can't use tools in your env to help you debug those issues. Probably makes sense decouple it.

This may require a bit of a rethink of the pyproject integration, but maybe not require <current_project> = { path = ".", editable=true } and just imply that maybe?? The just thinking out loud, but if uv can't install the package for the current directory, then maybe not fail to create a shell? Just hobble along? Would have to re-init your shell once your code does work unless we have an install command inside the env to reinstall the python package? This is gets meta of weird and I don't know the right answer but decoupling failing to install the current folder from the env maybe somehow is probably the right way to fix this deeper?

[tdejager]

Related issue: #1903

Maybe we should just create a source hierarchy for now if it does not exist?

I do agree with @zbowling that there is maybe more to this and we should think about it a bit more, but I feel it might be a good short term solution?