Projects that aren't meant to generate a wheel and `pyproject.toml`

[brettcannon]

@pf_moore

I’d like to see that, but I am aware it’s a bigger question than the one you originally asked

That’s totally fine! Sharing the blog post was to make sure what it proposed seemed reasonable for today (which my takeaway is people are supportive of it). I then tacked on my “I wish we were using a standardized file to record what has been installed”, and it led to this discussion which gets us to what will be reasonable eventually. You know I’m always supportive of standardizing stuff, so I’m still happy with where this has gone so far!

@pf_moore

The choice of how to declare dependencies is similar to (and I believe compatible with) that of pip-run, so could be the basis of a standard.

That would be great! I personally would support standardizing on a way to embed runtime requirements so it isn’t solely a pipx thing and something VS Code could utilize.

@pf_moore

Maybe what we need is simply better terminology, so that VS Code can say “If you’re developing a Python app…” and have it be clear that this doesn’t mean the same as writing a one-file script, or a notebook. But then we have to consider those apps that start life as a one-file script and become something that needs its own directory (i.e., pretty much everything I ever wrote ).

And that last is why we are currently planning to help users get to that stage upfront (at least to start).

@pf_moore

this is actually a very good use case for your VS Code situation. How would you expect to support a beginner doing Advent of Code?

Multi-root workspace if you wanted to have all of the problems open at once instead of viewing each problem as an independent project. Otherwise as one big project where you created a package per solution.

@pf_moore

And what it sounds like VS Code is looking at is more of a way to quickly get beginners to stage 3, rather than helping them at stages 1 and 2, and possibly even supporting them staying at those stages, if it’s appropriate to their needs.

Yes, because stage 1 leads you into stage 2 quickly and the leap is small when tooling can help you write down your dependencies. But stage 2 requires a way to write down those dependencies which we currently can’t do in a standardized way, hence us going straight to stage 3 where the baseline use case of being able to share things and not panic if you break your virtual environment is supported upfront. It’s all a question of which frustrations you’re trying to avoid.

@pf_moore

“Python packaging is hard” are saying that because they are at stages 1 and 2, and what we currently have is inappropriate for them.

I think to make stages 1 and 2 simpler we would need to be able to specify dependencies inside of a script to make that self-contained and take the guesswork of figuring out what to install out of the equation. After that is the transparent creation of virtual environments and the installation of dependencies as an inherent part of execution. That would take it from:

1. Write code (.py file)
2. Write down dependencies (requirements.txt)
3. Create virtual environment (venv)
4. Install dependencies (pip)
5. Run code (python)

to:

1. Write code w/ dependencies (.py file)
2. Run code (pipx run)

Both allow for redistribution and reproducible results, but the former can lead into more complicated flows naturally while the latter is much simpler and thus has less stumbling blocks.

I think the other question with this hypothetical is whether that latter approach is enough to go from “simple, self-contained, and no control” to “requirements file or pyproject.toml”? Or is that too much of a leap from stage 1/2 to stage 3? It’s probably fine as long as we never let the in-file dependency list allow for decisions, so no extras or anything else where the user might need to provide input.

I could imagine a world where if people could specify dependencies in a file, VS Code’s Run button (the green in the UI) would inspect the file and do the whole virtual environment creation and installation on the fly much like pipx run would do (heck, if we standardized the naming of the temp directory we could even reuse an existing one if people wanted to). That way beginners wouldn’t even have to think about it. And we could also provide code actions to help write down any packages necessary when an import clearly isn’t from the stdlib (which is where Record the top-level names of a wheel in `METADATA`? comes into play to help with that). We could even warn the user that we don’t think running the file will succeed due having not written down any dependencies (or they are running without a virtual environment).

One of the trickiest things we have to balance in VS Code is that golden path where we have to guess versus asking the user to participate in making decisions. In general we lean on the latter because we get yelled at less that way (although as you can tell from the blog post, we are getting asked to be opinionated to help beginners out). But if we had a more restrictive flow for the simple case where guessing wasn’t a concern then that makes it easier for everyone: we get to follow a standard/common practice that no one will argue with us over and users get exactly what they were expecting.