My POV as Ubuntu user: only recently I discovered py and I not installed the additional package because, well, if I don’t want to type python myscript.py every time, I put a shebang. On Windows, I use py because, well, it’s more short and Windows has no shebangs. Or I use git-bash and shebangs.
So IMHO py can warn about extensionless scripts to allow subcommands. Subcommands are cool. I don’t how much Windows users will be happy.
I don’t like the warning for all the interpreter invocations, for the problems the others has pointed out.
Why not use py --run <script> if you want to keep backward compatibility in py? If you want to backward compatibility in py, just make py run <script> the only way, and make py <script> an error. I do not see how is it related to python itself.
It’s related to python itself because people pay a lot of attention to what we do, and take their lead from that. They don’t like adopting “unofficial” solutions, and we may well stay stuck in the usability angst we’re seeing until we get something into our core distribution. (Again, if you’re not seeing it, please check out the discussions in Packaging.) But we don’t know exactly what that would be yet, all I can guess is that subcommands are popular and will probably remain that way.
Most tools that implement a tool run stuff sub-command scheme do this because they have to put the run stuff part into some specific context, e.g. download and install some packages into a temporary venv.
With py run stuff I currently don’t see the need for building such context, so there appears to be something missing in the proposal to justify the change. Why not beef things up a bit to make the UX case ? …
Python’s venvs were built following the virtualenv example.
Why not use a similar approach and have py run stuff follow the pipx lead or hatch case ?
(Let’s just hope that by the time all this is implemented, the PyPI supply chain attacks have been put under control )
Ugh. python is a language interpreter. It should interpret and run python files, and its commandline arguments should revolve around that process. The language interpreter does not need to init, install, build, publish, or anything else – unless we someday get to the point of creating binaries with the language interpreter(/compiler).
I wouldn’t get hung up on the run example that Steve provided, more that any sub-command could theoretically bump into the issue he’s pointing out.
But what I’m seeing here is people would prefer to have python left alone and any enhanced tool that may doing something fancy will have a different command name (or py) and that tool can decide how to handle this situation (i.e. always check for a name conflict and choose the file first, or ignore the conflict and always choose the command).
Steve (Dower), I feel pretty unhappy with how you handled this discussion. You put up a bunch of scary sounding speculation (“what if everybody would recommend never to use the python command”, “what if the recommended tool was owned by someone else”, “what if we didn’t approve of that owner”), mentioned a wildly speculative proposal (posted as an image so we can’t even go look at the context to find out how much support this has), plus the suggestion that if one hasn’t read the 100s of messages in the packaging forum one can’t really understand the issues. Not to mention an awkward triple negative (see quote above). I don’t think you’ve done anyone a favor with this approach.
That’s totally fair, I certainly take responsibility for not handling it well (I’m not particularly happy either). I also appreciate your saying so.
Python’s UX, particularly once packages become involved, has been an immensely frustrating topic for a long time, and that definitely bleeds through, while at the same time I care strongly enough about it to not simply let it go. Nobody has yet prepared a summary of the extensive discussions, and it’s very likely that such a summary would merely restart the discussion that was omitted from the summary (that’s happened at least a few times already). I could link to individual examples of people suggesting or raising concerns about everything I speculated, but that makes the discussion specific to either that person or the context of that particular example (again, it happens all the time).
The example was a screenshot from mid-podcast. There’s no way to gauge the support from its context, which is why I didn’t want to distract by linking to something that doesn’t help. There are plenty of similar examples of people proposing similar systems, all of which can be individually rejected on specifics, but all of which taken together show there’s a desire for a tool like this. I have nothing to do with the language summit this year, but I would highly expect someone will want to come and talk about an idea like this.
So honestly, I accept this wasn’t a great approach, but I’m a bit lost when it comes to finding a better approach. Must we start the discussion again from first principles? I’d prefer not to, as I’ve already spent way too much of my own patience on it.
I’ll try to summarise what I think triggered this thread (Steve - please correct me if I misrepresent you).
The packaging survey, and the discussions that came from it, highlighted one key desire from the user community - for a single, unified tool that people could use for all their Python development needs[1]. Such a tool doesn’t yet exist, and there are a lot of competitors in that space.
The existing policy of “core devs don’t do packaging” means that all of this is happening outside of the scope of the core devs’ and SC’s control, which has the potential to be problematic, as a unified tool like this could very quickly become what people think of as “Python”. Linux distros will have to consider how to include the tool in their “Python interpreter” offerings, trainers will be expected to cover it, and the core Python documentation will be under pressure to include at least some information about it.
The only stake the core devs have in this discussion at the moment is via the UI of the python command, and the py launcher. The motive behind Steve’s question (as I see it) is to consider whether we want to allow for the option of having a core tool as a contender in this debate[2], or whether we want to continue with the “hands off” stance, and explicitly accept that it will be decided by others. I will note that one of the discussion points is “how do we ensure such a unified tool is delivered with Python” - so ultimately there will be some form of impact on core, even if it’s only distributing another tool via an ensurepip style mechanism.
I should note that the existing delegations from the SC are largely ineffective here - there are no PEPs involved, so no-one is under any obligation to get any formal approval for what they do. Furthermore, to some extent the discussion goes beyond even the PyPA’s scope - there have been debates about the tool managing the Python interpreter (similar to rustup) and building standalone apps (something the PyPA has never covered).
So for me, that’s the crux of the matter here. Are the core devs (and the SC!) happy for these questions to be addressed and resolved externally, and to accept any implications on what users view as “the Python development experience”?
Personally, with my “core developer” hat on, I’m a little worried that we may end up with something that isn’t “the Python I know and love”. So I’m in favour of a little more involvement from the core devs on this issue, even if it’s not in the form of “making the python command do workflow” that Steve was suggesting.
Think of it as a Python equivalent of cargo, or npm. ↩︎
By reserving the subcommand space, so we can add such capabilities as subcommands. ↩︎
The closest relatives of Python as a CLI are Perl, Ruby, Tcl, Bash, Awk. But not Git and not package managers. Why not have different tools for different tasks? python for running Python programs, something other for creating a virtual environment and installing packages, something other for building packages and uploading on PyPI.
As important as packaging considerations are to people who develop packages, I think they are probably a microscopic fraction of the Python developer community, which is, itself a microscopic fraction of the Python user community. Making things ever-so-slightly more convenient for them seems like a case of a (very small) tail wagging a (very big) dog.
This is true, though most of the discussion was around what these people would do to support the regular users, who are the vast majority of the community.
I just realised that probably the most important starting point was locked, and so is a long way down the list. Here’s the thread started by PSF staff with results from a large survey that was run (in the first post): Python Packaging Strategy Discussion - Part 1
The Packaging category is the place where all discussion relating to virtual environments, installation, compilation, and deployment happens these days. (Maybe there’s some in the Help/Ideas categories too, but I don’t watch those.) It’s a long way from just package publishers.
We do. But the number one thing that regular users complain about is having different tools for different tasks (see the thread I linked above).
Oh, I finally get where this is coming from. The Rust community has all such tooling controlled by the core team. That’s a sensible model, just not the one that Python has chosen so far.
I appreciate the further explanations, I will crawl under my rock now.
So one possibility, then, would be to move the name python to a small selector-type program, that picks which of many subprograms actually get run, and not one monolithic executable? That does sound reasonable, but do we have the resources to tackle such a thing?
