Support --user flag from pip

Currently (even in latest uv 0.1.12 that supports --python flag) it's not possible to use uv in case --user flag of pip (or PIP_USER="true" env variable is set).
With --user flag, packages are installed to a ~/.local folder, which means that the user might not have access to the python system installation as a whole, but can locally install and uninstall packages, without having venv.
This is extremely useful for cases like CI and building container images, where having a venv is an extra overhead and it is unnecessary burden.
There is an interesting (and used in Apache Airflow) case for the --user flag (this currently prevent us from using uv by us and our users  also in PROD images in addition to our CI image). That is currently a blocker for https://github.com/apache/airflow/issues/37785
Why --user flag is useful and why we use it in Airflow?
Using --user flag is pretty useful when you want to have an optimized image - because such .local folders can be copied between different stage of the image (based on the same base image and prod libraries installed) and you can copy the whole .local folder between the stages after packages are installed - which means that the final stage of the image does not have to have build-essentials/ compilers installed.
You could do the same with venv if you keep it in the same folder, but that looses an essential capability of creating venv dynamically containing all the packages you have in your .local folder.  When you have your --user installed packages, and you create a new venv  with --system-site-packages,  the packages installed in .local folder are also installed in the new venv. This does not work when you create a new venv from another venv because --system-site-packages are only the ones installed in the system.
While I can think of some creative ways (maybe I will find some) - having an equivalent of --user installation by uv pip install would be a great simplification for our case to support the users who want to use uv (and seems that there is already a need for that looking at the https://github.com/apache/airflow/issues/37785

Thanks! I really appreciate the clear write-up and motivation here. (I'm hoping to get to this today, it's been requested a few times.)

Just to take off the pressure a bit. I figured out how to get rid of the --user flag (still have a problem to fix) https://github.com/apache/airflow/pull/37796 - I attempted it quite some time ago and failed but this time I got a brilliant idea - I simply deleted the ~/.local folder and created a new ~/.venv addde VIRTUAL_ENV and added ~/.local/bin to PATH and  .... voila ... It works 100% compatible with --user flag it seems - all the cases I had (including pip -m venve --system-site-packages work like a charm.
So ... It seems I do not need it that much any more .... I will make Airflow PROD image also uv friendly now :) (128s instead of 280s is the gain I have :). Not bad - another 55% improvement.
There is a small difference though with venv when using python -m venv and uv venv. With uv you do not have --system-site-packages option yet. That might be the more useful of the two.
After that experience I have a new thought. The --user flag has a few bad side effects (that's why I am glad to finally get rid of it). One of the problems is that you cannot run --user and --editable any more with pip. So maybe - just maybe (?), rather than implementing --user flag - documenting how to get an equivalent by creating ~/.local venv is a better option ?

@potiuk - At the very least I can add --system-site-packages, that's really easy. I'm somewhat undecided on --user... Gonna sleep on it.

@potiuk - At the very least I can add --system-site-packages, that's really easy. I'm somewhat undecided on --user... Gonna sleep on it.

Yep. That would be a good start :). I think pip maintainers would gladly drop that one. So my proposal for the uv team is think very deeply on whatever you add. You are now way faster on adding things and responding to new requests - comparing to pip -  but mainly because you do not have the whole baggage that pip accumulated over the years and where adding every single small change will make some loud part of your users unhappy. I think it should be a very conscious decision to add somethig that you will have to maintain in the future.

Yeah I strongly agree with this. Very good callout. It's nice to add things that unlock user workflows, but there are some areas where we actively want to change user behavior, and we need to hold firm on some of those lines.

Can I ask why you use --system-site-packages here?

Yes. In Airflow we have something called PythonVirtualenvOperator. Airflow has operators (4000+ of them 😱 ) that can do tasks related to some "stuff" to do - some of them are specific ("GoogleCloudJobOperator, ApacheSparkJobOperator, CreateEKSClusterOperator) but we have a number of a  few generic ones BashOperator, PythonOperator, ExternalPythonOperator` - runs python code on prepared virtualenv. All of those are unaffected, but PythonVirtualenvOperator is special - because what it does is:

creates a new virtualenv based on requirements, python version. One of the options (only valid if your python version matches the system version) is system-site-packages - when True, the new venv will have airflow and all airflow packages pre-installed. This is super important, because we serialize arguments that we pass to the operator, and de-serialze return value from it, as interface between airflow and the "new venv" method executed. And in order to serialize some objects, the target venv should have the "airflow + often other packages" installed. Moreover the python code to be executed (basically a methpd) can do some local imports - expecting airflow or other packages to be installed.

The --system-site-packages in this case is best, because you do not have to explicitly specify which airflow version or which other packages you have to have installed. You can specify extra dependencies to add - but having the base same as the Airflow execution environment is often necessary.
Here howto: https://airflow.apache.org/docs/apache-airflow/stable/howto/operator/python.html#pythonvirtualenvoperator
Here Python API: https://airflow.apache.org/docs/apache-airflow/stable/_api/airflow/operators/python/index.html#airflow.operators.python.PythonVirtualenvOperator

Under the hood, the operator does:
def _generate_virtualenv_cmd(tmp_dir: str, python_bin: str, system_site_packages: bool) -> list[str]:
    cmd = [sys.executable, "-m", "virtualenv", tmp_dir]
    if system_site_packages:
        cmd.append("--system-site-packages")
    if python_bin is not None:
        cmd.append(f"--python={python_bin}")
    return cmd

The way how it works now (just built and tested a new image):
With system-site packages:
airflow@a249d829a411:/opt/airflow$ python -m virtualenv --system-site-packages ~/.aaaa
created virtual environment CPython3.10.13.final.0-64 in 422ms
  creator CPython3Posix(dest=/home/airflow/.aaaa, clear=False, no_vcs_ignore=False, global=True)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/home/airflow/.local/share/virtualenv)
    added seed packages: pip==24.0, setuptools==69.1.0, wheel==0.42.0
  activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator
airflow@a249d829a411:/opt/airflow$ ~/.aaaa/bin/python -m pip freeze
adal==1.2.7
adlfs==2024.2.0
aiobotocore==2.12.0
aiofiles==23.2.1
aiohttp==3.9.3
aioitertools==0.11.0
aiosignal==1.3.1
alembic==1.13.1
amqp==5.2.0
anyio==4.3.0
apache-airflow @ file:///docker-context-files/apache_airflow-2.9.0.dev0-py3-none-any.whl
apache-airflow-providers-amazon @ file:///docker-context-files/apache_airflow_providers_amazon-8.18.0.dev0-py3-none-any.whl
apache-airflow-providers-celery @ file:///docker-context-files/apache_airflow_providers_celery-3.6.0.dev0-py3-none-any.whl
apache-airflow-providers-cncf-kubernetes @ file:///docker-context-files/apache_airflow_providers_cncf_kubernetes-8.0.0.dev0-py3-none-any.whl
apache-airflow-providers-common-io @ file:///docker-context-files/apache_airflow_providers_common_io-1.3.0.dev0-py3-none-any.whl
.....  AND 300+ other packages.

Without:
airflow@a249d829a411:/opt/airflow$ python -m virtualenv  ~/.bbbb
created virtual environment CPython3.10.13.final.0-64 in 113ms
  creator CPython3Posix(dest=/home/airflow/.bbbb, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/home/airflow/.local/share/virtualenv)
    added seed packages: pip==24.0, setuptools==69.1.0, wheel==0.42.0
  activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator
airflow@a249d829a411:/opt/airflow$ ~/.bbbb/bin/python -m pip freeze
airflow@a249d829a411:/opt/airflow$.

The --user flag has a few bad side effects (that's why I am glad to finally get rid of it). One of the problems is that you cannot run --user and --editable any more with pip. So maybe - just maybe (?), rather than implementing --user flag - documenting how to get an equivalent by creating ~/.local venv is a better option ?

@potiuk -- I'm trying to make a decision on whether to support --user. Do you have any references you could share for these side effects in pip? 🙏

@potiuk -- I'm trying to make a decision on whether to support --user. Do you have any references you could share for these side effects in pip? 🙏

The starting point I have is this:

And I think there were lots of related discussions:
Here is one: https://github.com/pypa/pip/issues/6375
And here is the PR that added the message above: https://github.com/pypa/pip/pull/6370
Looong discussions. But basically the gist of it is that --editable and --user do not play well together in the light of what has been agreed for PEP 517.
Personally I consider --user feature of pip as should be depreacated and besides the historical logic and the behaviour of making the .local venv automatically available for any venv, it has very little use, if you consider that you could create .local as a venv. I think it was introduced in https://peps.python.org/pep-0370/  and there were some discussions on deprecating it,
But I am not fully aware about some history behind .local and even less about future of it to make some "good" advice on it - treat it with a pinch of salt.
We luckily got rid the --user flag (and PIP_USER variable) even if pip version of our container images and Airflow 2.9.0 one (in a month or so) will not have it any more.

@potiuk Thank you for this issue, and thanks for the inputs you provided
Some of my thoughts regarding the comment above:

The starting point I have is this:

using the --system-site-packages while creating the virtual environment should make this error message gone.
If we take a step back, --user wouldn't be quite useful in this case since there's already an virtualenv.

And I think there were lots of related discussions. Here is one: https://github.com/pypa/pip/issues/6375

I skimmed through it, and it looks like the issue was mainly about --editable install breaking when there's pyproject.toml file.
It doesn't seem like --user flag had anything to do with it, since, according to the original issue: both pip install --user -e . and pip install -e . fail.
From what I understand, PEP 517 itself discusses allowing projects to specify different build systems through pyproject.toml. The build process should be independent from where the packages are installed. Not sure how that would impact user site installation.

Personally I consider --user feature of pip as should be depreacated ... there were some discussions on deprecating it,

--user was introduced over a decade ago in PEP 370.
I also saw this thread about deprecating it. some replies were not in favor of deprecation, for example:
Given that we're working towards making user site-packages the default
install location in pip, removing that feature at the interpreter
level would be rather counterproductive :)

Virtual environments are a useful tool if you're a professional
developer, but for a lot of folks just doing ad hoc personal
scripting, they're more complexity than is needed, and the simple "my
packages" vs "the system's package" split is a better option. (It's
also rather useful for bootstrapping tools like "pipsi" - "pip install
--user pipsi", then "pipsi install" the other commands you want access
to).

Cheers,
Nick.

If we do a quick search on GitHub for the --user flag: https://github.com/search?q="pip+install+--user"&type=code&p=1 we'll see it's still widely used
Though I haven't used --user much lately, thanks to venv and Docker containers, it's still a popular choice for many Python users for installing packages without needing admin privileges in many environments other than CI

Putting --user flag in uv would bring some of the complexity accumulated in pip over the years.
PR #2352 was my preliminary attempt to fit it into the uv pip implementation without introducing too much complexity as the script does the heavy lifting here.
I haven't looked into every combination of how --user flag would play with other pip flags, but it would take some effort to make it compatible with the behavior of pip for sure.
Ultimately, it's up to the uv team to decide whether to support it.

Virtual environments are a useful tool if you're a professional
developer, but for a lot of folks just doing ad hoc personal
scripting, they're more complexity than is needed, and the simple "my
packages" vs "the system's package" split is a better option.

This is an excellent quote, thanks @imfing for noting this. As somebody coming from the scientific Python world, I was meaning to write something along these lines in this thread as well.
Another useful framing of this is the distinction between a python project versus a single-file script. For the latter, having a separate venv for each individual script would not only be annoying but also error prone, as you'd need to be constantly activating / deactivating environments, when often all you need is stdlib and numpy/scipy.
We also have a rather odball use case for this -- we have a very unholy setup where we provide a system python installation in a container image with a lot of pre-installed packages, but we allow users to install additional packages to ~/.local, which is backed by a docker volume so that it is persisted when the container exits. We can't have separate venvs since we have a lot of packages installed in the system environment (e.g. the whole jupyter stack) and they can't be duplicated.
Small side note: If this feature is accepted, I think providing --user ahould also automatically enable --strict. That's what pip does as well, makes a lot of sense in terms of making sure the user knows if they broke themselves.
(all that said, it's brilliant that uv defaults to requiring a venv, that's already a huge change with respect to pip, and forced me personally to start using them, where previously I've used conda + pip, not a great combo. I never quite got myself to understand the various subtleties - venv x virtualenv etc.)

the simple "my packages" vs "the system's package" split is a better option

Note this perspective is something that we could solve with new workflows rather than matching the existing --user interface.
It's worth keeping in mind throughout this discussion that we will be building new workflows on top of the fundamental tooling we've built for pip-compatibility. If we can avoid implementing and maintaining something with complex compatibility concerns we can focus on innovation and comprehensive solutions.

It's worth keeping in mind throughout this discussion that we will be building new workflows on top of the fundamental tooling we've built for pip-compatibility. If we can avoid implementing and maintaining something with complex compatibility concerns we can focus on innovation and comprehensive solutions.

This is also my concern - I think (and Airflow use-case proves that) implementing something like that and having users rely on it should be conscious decision, because it will stay with uv once the versioning and compatibility rules are set (which is inevitable) and the more compatibility concerns and use cases you have the more it slows you down the moment you hit 1.0.0 version (assuming 1.0.0 and some kind of semver-ish approach will be adopted).
And --user is a bit a can of worms when you open it, to be honest - especially that uv also allows to create venvs and have some default reliance on venv being effectively required. Which is eventually a good thing even if few years ago I went into a long (and in hindsight unnecessary and far too heated) debate with pip maintainers over their push to venv being primary and the only valid way of installing python packages (especially in the context of docker containers). It even resulted with this medium article: https://potiuk.com/to-virtualenv-or-not-to-virtualenv-for-docker-this-is-the-question-6f980d753b46
I re-read that article again (it's really funny to read such an article few years later and confront your current views with the views of few-years-younger yourself).  Suprisingly (or maybe now), I tend to agree with that old-myself in  many of the things I wrote there, but with uv opening not only new chapter, but a new not-yet-written book, maybe there is a good solution that I can propose here?
I think PEP-370 proposal was good, and the reason described above (some people do not care about venv and they want to do things quickly) is very valid (recognising that non-power users want to just get-on with their install is also an argument in my article actually).
But the discovery I made in https://github.com/apache/airflow/issues/37785 that I can simply create a venv in ~/.local made me think that maybe we can connect venv creation and non-power users approach and both eat cake and have it?
What happens currently when you start uv pip install without a venv ? You get an error telling you tha tno virtualenv is detected and possibly that you can use --python to point to a python installation.
Is it good for non power users ? Not at all. It's confusing for first time users who have no knowledge about venv and they have no idea where their python is. Do we want to teach them that? I am not sure. We do not want to teach people all the details about venv etc. if all they want is to instal some package and use it, and even less if they are running uv pip install in their Dockerfile. What we want instead - we want them to USE venv. Even if they have no idea they are doing it.
But wait - we already have a way to create venvs (fast) in uv that we fully control here.... Why don't we ..... create venv for such user? Why don't we ..... create it in ~/.local (or equivalent place on other system)  automatically if it is not there (and we can even check if ~/.local/bin is in the path and suggest the user to add it to make use of installed entrypoints.  That's also nicely compatible with PEP-370 (which is more about using the ~/.local installation place rather thatn creating it.
That would be my proposal in short:

forget the --user flag
fallback to creating / using ~/.local venv when no virtualenv and no --python flag is used

Just to say - I too would be very interested in a mechanism to support beginners who do not yet know about virtualenvs.   I have taught a lot of students to use Python for data analysis, including data science.  In practice these beginners (and there are lot of them) will not need to (consciously) make virtualenvs for a while - because the standard Python data stack is pretty stable, and doesn't generate many dependency conflicts.   I'd estimate these beginners can make six months or more of progress before they need to start thinking about making and switching virtualenvs.   I think it will be a significant barrier if they have to learn virtualenvs and their structure before they install their first Python package.   So I would love a solution like @potiuk's - where the user can ask for, or even just be given, a default virtualenv, into which they install their packages.   Of course the --user install provides something like this, but I agree with @potiuk - a default virtualenv is preferable - and in fact I already found myself making that suggestion over at this homebrew discussion.  I really care about this, so I am very happy to help with anything I can to test or even build (when term finishes in a couple of weeks).

In case it's helpful - the use-case I have in mind is - I believe - very common - and that is the beginner starting a class or an online tutorial.  For example, consider this tutorial:
https://realpython.com/pygame-a-primer/
It has the instructions, right at the top, of:
pip install pygame

Or - for my students, I suggest:
pip install jupyterlab numpy scipy matplotlib

In both cases, this gets the beginner going with early Python work.    But - with various installation methods - including uv pip as stands, outside Conda, this gives e.g.:
$ uv pip install pygame
error: Failed to locate a virtualenv or Conda environment (checked: `VIRTUAL_ENV`, `CONDA_PREFIX`, and `.venv`). Run `uv venv` to create a virtualenv.

Of course this isn't going to worry an experienced user, but it will be very confusing to a beginner, who does not know what a virtualenv is - and - for a beginner, who doesn't understand Python installation structure, the virtualenv is a relatively advanced subject.
So - it would be very good to have some default set up, such that the beginner would not face this learning curve immediately, but face it later, when their needs and experience have expanded.
I'm posting here because I have, up until now - suggested my students do e.g. pip install --user pygame as a workaround, but I can see the arguments against doing that.

Maybe the topic, of whether or not to add a --user flag obfuscates the main concern here:
New users, as @matthew-brett mentions, are often given "pip install x" instructions. This should ideally just work, and definitely not raise obscure errors that confuse new users who know nothing about virtual envs.
Ideally, I'd imagine something like: it in venv, install there, otherwise install into a local default venv. The local default venv has access to system packages, but shadows them, so that the user can upgrade packages.
This would make for a simple first user experience, compatible with all tutorials out there, without impacting sophisticated users who can set up their own venvs.

This should ideally just work,

Yep. My proposal is that it will just install things in .local (or equivalent on other systems) venv created and used automatically by uv in this case. Bonus point to print warning if .local/bin is not on PATH

I would definitely love that
When you're already working in a containerized development environment (nix shell / devcontainer …), it makes perfect sense (and even should be the default)

Yep. My proposal is that it will just install things in .local (or equivalent on other systems) venv created and used automatically by uv in this case. Bonus point to print warning if .local/bin is not on PATH

I wonder though, whether anyone would worry about previous --user installs either being overwritten, or appearing unexpectedly in the uv environment?    And where would the packages go?   In .local/site-packages or somewhere else?

As of today, it's still not possible to use uv in immutable (where --system couldn't work) containers (such as Codespaces) without an useless venv
This issue would be very appreciated for Codespaces users

As of today, it's still not possible to use uv in immutable (where --system couldn't work) containers (such as Codespaces) without an useless venv

You could use --target as a workaround, and point to /home/codespace/.local/lib/python3.10/site-packages/. For example, in a blank workspace with Python 3.10:
/workspaces/codespaces-blank $ uv pip install --target /home/codespace/.local/lib/python3.10/site-packages/ -p /home/codespace/.python/current/bin/python3.10 flask
Resolved 7 packages in 55ms
Downloaded 5 packages in 38ms
Installed 5 packages in 8ms
 + blinker==1.8.2
 + click==8.1.7
 + flask==3.0.3
 + itsdangerous==2.2.0
 + werkzeug==3.0.3

/workspaces/codespaces-blank $ python3.10 -c "import flask; print(flask.__version__)"
3.0.3

Could you share a bit more about why the "useless" virtual environment matters? It seems like the overhead of creating it should be negligible.

@zanieb For us, we use containerized cloud development environments because our users aren't technically advanced enough to understand virtual environments. So we use development containers to offer the same project isolation. This works perfectly with pip, where we can just have them clone the repo, run pip install -r requirements.txt and have the packages installed to the $HOME/.local directory. Having them run commands they don't understand to create a venv and activate it every time they log in (or maintaining scripts to automate this) is something we'd rather not have to deal with to get the performance improvement of uv.

As a work around, currently for our devcontainer we have (effectively):
	"postCreateCommand": "uv venv && uv pip install -r ${PROJDIR}/requirements.txt",
and in our production Dockerfile:
ENV VIRTUAL_ENV=/app/.venv

# Copy files and other setup here

RUN uv venv && \
    uv pip install -r ./requirements.txt && \
    uv pip install -e .

I would prefer if inside the containers we didn't need to have a virtual environment at all though.

@jbcpollak @eswolinsky3241 to avoid creating the virtual environment, this may be a workaround:
FROM python:3.10-slim
RUN pip install --no-cache-dir uv

RUN uv pip install \
    --python $(which python) \
    --target $(python -m site --user-site) \
    -r requirements.txt

it should behave the same as using the --user flag by installing the packages into user site (my requirements.txt contains only requests):
docker run --rm -it --entrypoint python 217c1ad27560 -m pip list
Package            Version
------------------ --------
certifi            2024.6.2
charset-normalizer 3.3.2
idna               3.7
pip                23.0.1
requests           2.32.3
setuptools         65.5.1
urllib3            2.2.1
uv                 0.2.6
wheel              0.41.2

Another workaround to using uv in codespaces.

Just a meta-point here - as I said above - I teach a lot of beginners - and to beginners, using a virtualenv is extremely confusing - because you really have to understand the details of a Python installation - which is far too much for a beginner coder to take on.   I mean the type of code who is still learning for-loops.  And of course, we're very often teaching Python to beginner coders.    Unfortunately - but inevitably - installation tools tend to be written by very experienced developers, to whom virtualenvs are no barrier.    But I can assure you from long long experience that virtualenvs will be a barrier to beginners.   Just for example, my third year students, who already know Python and Git and Python data science libraries - got pretty edgy when faced with pyenv in a class - despite some explanation - and even for them, it would have been a few hours of explanation and practice to get them into a state where they were ready to experiment with virtualenvs.
On the other hand - it seems to me this is very easily soluble by having a default virtualenv - where the user would need to understand virtualenvs only at the point that they really need them - when they get version conflicts or start serious development.

Nice workarounds,
Do you know if there is a current workaround (no --user)

Without "remoteUser": "root"
Working on immutable (/ rootless) systems (such as codespaces…) AND on mutable systems (such as regular Docker devcontainers)
No hardcoded target (i.e. hardcoding the "/home/codespace/.local/lib/python3.10/site-packages/" string)

?

@Malix-off check out my other comment for Dockerfile: https://github.com/astral-sh/uv/issues/2077#issuecomment-2150232739 root is not needed, and usually not recommended.
The hardcoded target user site-packages directory can be easily retrieved via python -m site --user-site:
uv pip install \
    --python $(which python) \
    --target $(python -m site --user-site) \
    -r requirements.txt

It works for both codespaces as I commented in https://github.com/astral-sh/uv/issues/2077#issuecomment-2150008781 and docker containers https://github.com/astral-sh/uv/issues/2077#issuecomment-2150232739

@matthew-brett fwiw we're trying to address those problems holistically in new CLI interfaces instead of just tacking on a workaround to the uv pip interface.

@matthew-brett fwiw we're trying to address those problems holistically in new CLI interfaces instead of just tacking on a workaround to the uv pip interface.

Nice - thanks - is there a good place to look for that?

All of the new interface work is labeled as preview. We'll be publicizing more user-facing content in the next couple months.

Indeed @imfing, it seems your workaround is the best until this issue is solved !

I am testing @imfing's workaround
I get different results between uv pip list and pip list after running
uv pip install \
	--python $(which python) \
	--target $(python -m site --user-site) \
	fastapi

@Malix-off this is expected as uv pip list doesn't look for packages other than virtual environment or system site-packages (if --system is specified). However, both python and pip would use user site packages directory (PEP 370)
uv pip compile and uv pip sync support --target flag, but uv pip freeze doesn't.
It is also worth mentioning that the default Python system packages could be ignored if --target is provided since it makes uv pip to only search for packages under the target directory.

Okay, thanks for that clarification!
We will still to using venv for now, until --user is available

To clarify, there's a good chance that we'll never support --user. The user install scheme predates virtual environments. If virtual environments existed today, but the user install scheme didn't, I'd be very surprised if the user install scheme would be added to the packaging ecosystem.

To clarify, there's a good chance that we'll never support --user. The user install scheme predates virtual environments. If virtual environments existed today, but the user install scheme didn't, I'd be very surprised if the user install scheme would be added to the packaging ecosystem.

That's quite possible - requiring virtualenvs was clearly attractive to the pip maintainers - as seen here : https://peps.python.org/pep-0704 .    I suspect the reason that --user installs have persisted is the one I and several others have given above - virtualenvs are hard to explain to beginners, and a frequent source of confusion - but that is much less true for adding --user to pip install.

requiring venv by default but allowing user install with an explicit --user seems to be the best of both worlds
venv is bloat in devcontainers.

Requiring venv by default but allowing user install with an explicit --user flag seems to be the best of both worlds

Requiring venvs by default means that the users who are most likely to be confused will get the default behavior, and have to work out how to avoid it.   --user is better than nothing for those users, but having a default - invisible to user - virtualenv is even better, in my opinion.

Requiring venvs by default means that the users who are most likely to be confused will get the default behavior, and have to work out how to avoid it.

having a default - invisible to user - virtualenv is even better, in my opinion.

So you want

uv pip install to execute uv venv && source .venv/bin/activate if no venv is already present
uv pip install --user to allow install in user's python

?

So you want
* `uv pip install` to execute `uv venv && source .venv/bin/activate` if no venv is already present

* `uv pip install --user` to allow install in user's python

No - not uv venv && source .venv/bin/activate - because part of the problem with virtualenvs is explaining to the user why they have to do .venv/bin/activate to get their installed packages.   With that result, when the beginner closes their terminal and start it again, perhaps with another working directory, they'll be in some trouble.
What I would like is for uv pip install pygame to just work(TM) for a beginner user, with no further setup, such that, when they close their terminal and start it again later, they can do e.g. import pygame.
One way that might work, is to follow the conda pattern - there is a default environment, that the user is installing into, often without them realizing it.   When they get more advanced they can make new environments and switch to them.
For pip, I am wondering if this can be achieved with a default virtualenv, say in ~/.venvs/default.   When the beginner does uv pip install pygame, instead of seeing error: No Python interpreters found in virtual environments, uv creates ~/.venvs/default if necessary, installs into that virtualenv, and activates it (as you've suggested, except with the standard location).     There is some default or simply-enabled setup that activates this virtualenv by default on starting a terminal, if no other is activated - so the user will by default be able to restart the terminal and do python -c "import pygame".
With that working, I think --user becomes an unnecessary confusion, and I'd be happy to see it go.

Actually as an author of the issue I stopped needing it. And @charliermarsh @zanieb - feel free to close that one if you feel that you do not want to implement --user flag.
I was in the same camp "venv in container images is a bloat" - and this was for me the main reason why I opened the issue, but since then I found out that when I create venv in ~./.local - and simply set VIRTUAL_ENV vatiable to point to it and having ~/.local/bin on the PATH  as first entry does precisely what everyone needs here:

no need to explain user to do `activate'
activate merely sets the VIRTUAL_ENV variable and inserts PATH entry - and this is as specified in venv defintion, so you can do precisely the same in your container image or environment definition
it also nicely retains packages installed in .local when you create a new virtual environment (which was the reason why I opened the issue) - which means that you can nicely create and activate new venvs from such .local venv
this all adds virtually no overhead comparing to --user flag

I believe now that there is no particular reason to have --user flag, really. People who say that they do not want to maintain extra scripts are really talking about running two commands. People mentioned in the discussion thread here, that  they do not want to teach their users about venv, and the approach above 100% solves that. You don't have to. You just create the venv and set the right environments for them and they can continue using uv pip install or pip install  and it will just work. Mission accomplished.

BTW. Kind request - If someone would like to discuss whether to use some .venv by default, this is NOT the right place to discuss it. This is a discussion about the --user flag.  Whether to use a venv by default is very tangential to the --user flag and I think if someone would like to discuss it, they should open their own issue/discussion, rather than hijack this issue -  which was initially on ly for --user support.

The associated pull request was just closed minutes ago
Does that mean that devcontainers and codespaces will never be able to use uv without the venv bloat?

We didn't close the pull request, the author did because they have a clear work around.
I think the trade-offs discussed here are not suggesting that we should add this flag. I don't think that means that we'll definitely never add the flag, just that the current evidence is not in favor of it.
I don't really see "virtual environment bloat" as a real problem, they're very lightweight and if you want to bypass it there are a couple workarounds. If this is a big deal to you, I think you'll need to provide more information on why.

What I would like is for uv pip install pygame to just work(TM) for a beginner user, with no further setup, such that, when they close their terminal and start it again later, they can do e.g. import pygame

This is the most compelling argument for user-level installations, but mutable global environments have been repeatedly shown to be the source of a great deal of confusion and problems. We'd like to solve this problem in other ways.

Does that mean that devcontainers and codespaces will never be able to use uv without the venv bloat?

My experience is tha venv is about the same bloat as what gets created with --user flag. But this has been discussed here and elsewhere -  i.e. approach where venv will be created automatically for you if not existing, that seems much more consistent approach, though I think it's the question or where and how it should be created. I think it's quite appealting and constructive discussing that possibility is probably best we all can do.
As the author of that issue, I am also OK with closing this one, because I also agree with @zanieb that just "straightforward" --user flag rip-off from pip is not the best appraoch.
Ideally, maybe we should discuss and agree a new PEP how venvs should be automatically created  for the out-of-the-box cases?

Just to answer the previous post - why mix the discussion of --user and default virtualenvs? - because, if there are no immediate plans for a "just-works" solution for the beginner, such as default virtualenv, then I would be interested in having the --user option as a not-quite-as-good solution to the same problem - even if it was only temporary.

Just to answer the previous post - why mix the discussion of --user and default virtualenvs? - because, if there are no immediate plans for a "just-works" solution for the beginner, such as default virtualenv, then I would be interested in having the --user option as a not-quite-as-good solution to the same problem - even if it was only temporary.

When you build product (like the uv team does) - temporary solutions usually turn into long-term maintenance headache, because those who start using it expect it to continue working. So while you might have a wish to solve your problem, you have to understand that maintainers will have to live with those decisions for a long time.

Ah yes I understand - and I do build product.  But I do want to push back on "your problem" - it's really not my problem - but a problem that will be common for beginners.

Ah yes I understand - and I do build product. But I do want to push back on "your problem" - it's really not my problem - but a problem that will be common for beginners.

So let maintainers solve it in their due time. Without pushing them, as they have likely many other things to work on wich are likely higher priority.

because, if there are no immediate plans for a "just-works" solution for the beginner

These plans are immediate; we're building out next-generation workflows on top of the foundation we built for uv pip right now. These workflows are intended to abstract virtual environment management. We'll have more to announce on this front soon.

So, UV makes it impossible to use python without a .venv, because you purposely disable the --user.
For me, a non-noob user but new to the mess of python ecosystem, and also using normal tools such as containers instead of virtual environment, .venv is just a different workflow which is more manual and prone to error, including which I have trouble solving currently.
I was hopping Astral to unify things
It makes them worse for me

Frankly, we don't make it impossible to use Python without a virtual environment. We allow installing into non-virtual Python environments in a myriad of ways, e.g., with --python <path> or --system. There are workarounds for user-level installs, e.g., using --target. There are ways to avoid manual activation of the environment. Additionally, we are actively building workflows for uv that do not require you to ever manually manage a virtual environment.
I understand you don't have write permissions to the system site packages in your devcontainer context and that means you need to understand a bit more to set up your environment. However, we must take into account the trade-offs for the situations of many users.

Are --python and --target available on every uv pip commands (or --python available for some commands and --target for the other, or some commands don't support either) ?

Which flag + argument would be a 1:1 behaviour replication to --user for all uv pip use-cases ?

you need to understand a bit more to set up your environment

For my use-case, understanding .venv would still be inferior to using raw --user (or another 1:1 flag + command), even if I was willing to specifically understand a bit more python's .venv

However, we must take into account the trade-offs for the situations of many users.
I don't understand how allowing --user, while still continuing to not recommend it anywhere to make it foolproof, would be an inferior trade-off compared to not making it possible for those who want to use --user (and would know they want it, at that point)

I see your post was edited a bunch times while I was writing this, sorry if I've responded to something out of date

Yes, no problem it's still up-to-date 🙂

Are --python and --target available on every uv pip commands

--python is available on all of the uv pip commands. --target is available on mutating commands like install, uninstall, and sync.

Which flag + argument would be a 1:1 behaviour replication to --user for all uv pip use-cases ?

Generally the invocation looks like this:
❯ uv pip install --target "$(python3 -m site --user-site)" fastapi
...
❯ python3 -c "import fastapi; print(fastapi.__version__)"
0.111.0

Note this was also discussed further up in this thread.
I think we'd need to add --target to the other commands if you want to use it for inspection — which I don't see an immediate problem with, nobody has asked for it yet.

or my use-case, understanding .venv would still be inferior...

Perhaps you would find this draft documentation helpful https://github.com/astral-sh/uv/pull/4433

I don't understand how allowing --user...

I think you've been quite clear that you want the --user flag — we appreciate the feedback but we'd rather focus on new ways to address this use-case. While it may not seem like much effort to add, we are ultimately responsible for maintaining this tool for years to come.  Let's try not to rehash the discussions we've already had here and focus on new perspectives and use-cases.

I've settled on "faking" a venv in my environments so I'm fine without --user but I wanted to point out this:

Generally the invocation looks like this:
❯ uv pip install --target "$(python3 -m site --user-site)" fastapi
...
❯ python3 -c "import fastapi; print(fastapi.version)"
0.111.0

Does not seem to work, at least on Windows. Some of my team are still using "bare" Python installs on windows and global installations of dependencies, but when I try the above command (adapted the path resolution to Windows), I get the error about no venv found. Is that supposed to be bypassed when using --target?

@jbcpollak I remember both --target and --python are needed
See my previous comment:
https://github.com/astral-sh/uv/issues/2077#issuecomment-2150406001
uv pip install \
    --python $(which python) \
    --target $(python -m site --user-site) \
    -r requirements.txt

This workaround doesn't seem to create a /bin sub-directory the way --user does?
Testing on uv version 0.2.33 I believe.

Which workaround are you referring to?

Which workaround are you referring to?

The one mentioned in this comment:
https://github.com/astral-sh/uv/issues/2077#issuecomment-2150406001

Which workaround are you referring to?

The one mentioned in this comment: #2077 (comment)

@sqrl use --prefix instead of --target should work better in this case:
uv pip install \
    --python $(which python) \
    --prefix $(python -m site --user-base) \
    -r requirements.txt

See https://github.com/astral-sh/uv/issues/2059#issuecomment-2227402333 and https://github.com/astral-sh/uv/pull/4085

Hi - sorry - I scanned the preview labels - but couldn't see the proposed solution for having a default virtualenv - did I miss it?  Or is it still in progress?

As this seems to lead into a lot of confusion and keeps resurrecting, here's a recipe.
Amend your own base container (concatenated as a multistage image for brevity / being a self contained demo):
FROM python:3.12-slim-bookworm as setup-user
# Always run your end software as non-root!
RUN useradd -ms /bin/bash python
USER python
WORKDIR /home/python

FROM setup-user as setup-venv
# Setup upstream standard venv
#
# XXX - as upstream venv gives you setuptools and friends, those should also
# be pinned in a separate requirements-setup.txt or such and installed in a
# separate bootstrapping phase to keep things actually well defined and
# stable as they get bumped forward when the upstream Python image gets
# updated - omitted for clarity here.
#
# The three lines below are probably what you're missing from stuff
# "just working"!
RUN python -m venv .venv
ENV VIRTUAL_ENVIRONMENT=/home/python/.venv
ENV PATH=/home/python/.venv/bin:"$PATH"

FROM setup-venv as setup-uv
# XXX - This would be defined via a requirements-uv.txt or such in real use.
RUN pip install uv==0.3.3

FROM setup-uv as use-uv
# XXX - This would be defined via a requirements.txt or such in real use.
RUN uv pip install pyfiglet==1.0.2

FROM use-uv as everything-works
# Separating ENTRYPOINT and CMD is in general a nice idea
ENTRYPOINT ["pyfiglet"]
CMD ["uv rocks!"]

Then on the downstream consumer side in your org the consumer can simply pip install or uv pip install as they please and everything will happen via that predefined venv as intended.
IMO no changes on the side of uv needed. Feature parity with all sins of the past is not the way forward.

Just to clarify - you can read the details further up, but the use-case here is the absolute beginner, running the equivalent of uv install pygame, in their default Python environment, and without having to explain virtualenvs.

Hi - sorry - I scanned the preview labels - but couldn't see the proposed solution for having a default virtualenv - did I miss it? Or is it still in progress?

We didn't introduce any preview behavior around this — we're probably not going to support a --user flag or a default virtual environment.

When working with devcontainers or nix , forbidding to use an explicit --user flag (and thus forcing to use a venv anyway) is a net negative

Aha - ouch - well - I'm afraid that will make uv inaccessible to beginners - but I understand you have to optimize to some subset of users ...

I guess the plan will be to propose uv to more advanced users who are comfortable with virtualenvs.   But that will necessarily mean some division of the user-base - with some using uv and others starting, and perhaps continuing with some other tool, that does allow just-works installs without understanding virtualenvs.

We very much care about supporting beginners and eliminating the need to understand virtual environments — but we don't think a global mutable environment is the way to do that.

Aha - could you say more about other approaches you are considering?

One caveat to bear in mind when skipping using a venv and instead using --user with the global Python installation: If you are using a relocated Python install, some tooling doesn't correctly locate the stdlib out of the box, eg:
https://github.com/unbit/uwsgi/issues/2525
Working around that requires setting PYTHONHOME explicitly, which then comes with its own set of issues.
In contrast, support for PEP-405 style venvs seems much more prevalent.
It's for this reason that I'm in the process of migrating the Heroku Python CNB to use a venv in the layer containing the app dependencies instead of a user site-packages installation.
If you are using a non-relocated Python install (such as the Python in the python:* images on Docker Hub), then this issue doesn't apply. But it's something to bear in mind wrt the "venvs aren't needed for containers" argument, since it's not always correct.

Do that mean that the python ecosystem has some dependency on venv usage ?

More that:
(a) by design venvs are in a different location from system Python so tooling can't avoid handling the sys.prefix vs sys.base_prefix distinction, which sidesteps any issues with relocated Python if the packaging/tools don't do the right thing otherwise
(b) in general venvs appear to be the more well-trodden path, since so many workflows/tools now use them by default (eg Poetry, Pipenv, uv) - and sticking to the well tested path tends to result in fewer surprises overall

Understandable, but isn't relocating supposed to be solved by fixing the path in /usr/bin/env too ?
Understandable too, are there any other language than Python having venv ?

Understandable, but isn't relocating supposed to be solved by fixing the path in /usr/bin/env too ?

No that doesn't help. Please see the STR in https://github.com/unbit/uwsgi/issues/2525
(we're getting a bit off-topic here, so this will be my last reply :-) )

We very much care about supporting beginners and eliminating the need to understand virtual environments — but we don't think a global mutable environment is the way to do that.

I was (as you probably saw) following the discussion over at Scipy - could you say more about the current state of play for this?  Is there a recommended uv way of avoiding the need to understand virtual environments?   Or is there one in the pipeline?

... could you say more about the current state of play for this? Is there a recommended uv way of avoiding the need to understand virtual environments? Or is there one in the pipeline?

The current state is that you need declarative metadata, either in a project (via pyproject.toml) or a script (via PEP 723 metadata). I want to do more for people that want to manage declarative environments outside of those contexts, e.g., an environment you'd re-use for analyzing data in several projects — but we have not designed that yet.

Do you think there will be a route to using uv that does not require specific activation of an environment or getting the environment from the current directory or specific declaration of dependencies?   I mean, similar to the workflow with the default environment of conda?  Or is that unlikely in the near future?


GridFieldEditableColumns & Checkboxes

Using this component for a many_many_extrafield (Boolean or Int) with a CheckboxField allows me to set the value, but not unset.
I've tested with both array & closure, same results. Is this a bug in GFE?

I just ran into this problem, wasted a few hours trying to figure out what was going on.
Editable columns seems tp need atleast one other textfield (that is not readonly) when saving an unchecked checkboxfield.

Might be worth submitting some docs about this.

Still running into this is issue. I'm using a gridfield with checkboxes in multiple columns, no editable text fields. It is not possible to save unchecked checkboxes. Any solutions?

Workaround: It works if you use optionsetfield instead of checkbox:
    $SConfig->getComponentByType('GridFieldEditableColumns')->setDisplayFields(array(
				'Active' => array(
					'callback' => function ($record, $column, $grid) {
						return new OptionsetField($column,$column,array(1=>'Yes',0=>'No'));
					},
					'title' => 'Actief'
				) // ...... etc

Looks like this:

Added some styling to the optionset to make it compact:
Requirements::customCSS('.ss-gridfield .optionset li{width:auto;margin-right:10px;}');

@RVXD thanks man that works like a charm :)

I have just run into this issue as well, using an OptionsetField like @RVXD suggests works but does take up more space (which isn't always ideal) :-s

4+ years but just ran into this problem with an CheckboxSetField as well. Worked around it by appending a hidden input when a checkbox gets unchecked (so a '' value gets submitted).
(Old fashioned jQuery & Entwine:)
// make empty/unchecked checkboxfields (inside GridFieldEditableColumns) submit ''
// instead of not submit anything
$('.ss-gridfield-item input[type="checkbox"]').entwine({
    onchange: function (e) {
        // insert/remove a hidden input with value '' to submit unchecked checkboxes
        if(this.prop( "checked" )){
            this.siblings('.checkbox_zero_input').remove();
        } else {
            $('<input>').attr({
                class: 'checkbox_zero_input',
                type: 'hidden',
                name: this.attr('name')
            }).insertAfter(this);
        }
        this._super();
    }
});

Hey @micschk are you still using SS3 or have you managed to come across this issue in SS4 as well?

SS3, but should work for 4 as well (could be that the class/selector needs to be slightly changed).

Sorry I was trying to understand whether you've encountered the reported bug in SS4.
Unfortunately, SilverStripe 3 has entered limited support in June 2018. This means we'll only be fixing critical bugs and security issues for SilverStripe 3 going forward.
You can read the SilverStripe Roadmap for more information on our support commitments.
If this bug is still prevalent in SS4 then I'm happy to reopen this issue 🙂

In SS4 this issue is still prevalent.

Still an issue in 2020.
Solution for SS 4:
Add this to config.yml:
SilverStripe\Admin\LeftAndMain:
  extra_requirements_javascript:
    - 'app/client/dist/js/cms.js'

Create file app/client/dist/js/cms.js with content as @micschk suggested:
(function ($){
  $('.ss-gridfield-item input[type="checkbox"]').entwine({
    onchange: function (e) {
      // insert/remove a hidden input with value '' to submit unchecked checkboxes
      if(this.prop( "checked" )){
        this.siblings('.checkbox_zero_input').remove();
      } else {
        $('<input>').attr({
          class: 'checkbox_zero_input',
          type: 'hidden',
          name: this.attr('name')
        }).insertAfter(this);
      }
      this._super();
    }
  });
})(jQuery);


Document i18n

Explain Transifex and how to set up and translate questionnaires.

Coverage increased (+0.5%) to 80.86% when pulling 6f6bcc46069313b4324634eb3ea89662e99a9e6d on feature-document-i18n into 2f6f27c862fbda433efe9313eba41bee4f8125c3 on staging.

Coverage increased (+0.5%) to 80.86% when pulling 6f6bcc46069313b4324634eb3ea89662e99a9e6d on feature-document-i18n into 2f6f27c862fbda433efe9313eba41bee4f8125c3 on staging.

Coverage increased (+0.5%) to 80.928% when pulling 22657fcba74dcb19f20cc6d44369ee48e38e1373 on feature-document-i18n into e8d3052661e0e25cda0f2adf4d85a1d177d01cfe on staging.


Update supported Python versions

Python 2.6 and 3.3 are EOL and no longer receiving security updates (or any updates) from the core Python team.
They're also little used.
Here's the pip installs for atomicwrites from PyPI for June 2018:

python_version
percent
download_count

3.6
72.14%
878,675

2.7
19.73%
240,284

3.5
5.87%
71,478

3.4
1.92%
23,405

3.7
0.30%
3,703

3.3
0.03%
354

2.6
0.01%
139

3.8
0.00%
31

3.2
0.00%
8

None
0.00%
6

Total

1,218,083

Source: pypinfo --start-date 2018-06-01 --end-date 2018-06-30 --percent --markdown atomicwrites pyversion
This also adds Trove classifiers, and python_requires to help pip.

Thanks!


Subquery in select can't parse expectantly.

What steps will reproduce the problem?
Here is my example query builder :
$subQueryFollow = SpecialSubjectFollow::find()->alias('sfb')->select('sfb.ssu_id')
            ->where(["sfb.ss_id" => "ss.ss_id"])->limit(1);

$subQueryTopic = Topic::find()->alias('tsb')->select(["tsb.title"])->where([
            "tsb.module_id" => "ss.ss_id",
        ])->limit(1);

$query = SpecialSubject::find()->alias('ss')->select([
            "ss.ss_id",
            "ss.title",
            "topic_title" => $subQueryTopic,
            "follow_status" => $subQueryFollow,
        ]);

print_r($query->createCommand()->getRawSql());

My expected parse results are
["tsb.module_id" => "ss.ss_id"] to `tsb`.`module_id` = `ss`.`ss_id`

and
 ["sfb.ss_id" => "ss.ss_id"] to  `sfb`.`ss_id` = `ss`.`ss_id`

, but the results now are
["tsb.module_id" => "ss.ss_id"] to   `tsb`.`module_id` = 'ss.ss_id'

and
[ "sfb.ss_id" => "ss.ss_id"] to  `sfb`.`ss_id` = 'ss.ss_id'

What is the expected result?
SELECT
	`ss`.`ss_id`,
	`ss`.`title`,
	( SELECT `tsb`.`title` FROM `hh_topic` `tsb` WHERE `tsb`.`module_id` = `ss`.`ss_id` LIMIT 1 ) AS `topic_title`,
	( SELECT `sfb`.`ssu_id` FROM `hh_special_subject_follow` `sfb` WHERE `sfb`.`ss_id` = `ss`.`ss_id` LIMIT 1 ) AS `follow_status`
FROM
	`hh_special_subject` `ss`

What do you get instead?
SELECT
	`ss`.`ss_id`,
	`ss`.`title`,
	( SELECT `tsb`.`title` FROM `hh_topic` `tsb` WHERE `tsb`.`module_id` = 'ss.ss_id' LIMIT 1 ) AS `topic_title`,
	( SELECT `sfb`.`ssu_id` FROM `hh_special_subject_follow` `sfb` WHERE `sfb`.`ss_id` = 'ss.ss_id' LIMIT 1 ) AS `follow_status`
FROM
	`hh_special_subject` `ss`

Additional info

Q
A

Yii version
2.0.30

PHP version
7.3.6

Operating system
Ubuntu 18.04.2 LTS

The values in Key->Value pairs are treated as data so will be encapsulated as strings.
If you want to specify a column you need to use an yii\db\Expression.
$subQueryFollow = SpecialSubjectFollow::find()
  ->alias('sfb')
  ->select('sfb.ssu_id')
  ->where(["sfb.ss_id" => new yii\db\Expression("ss.ss_id")])
  ->limit(1);


Insert line breaks into long constant

Not tested.
I spent a few minutes searching with permutations of long, literal, constant, line, break etc. via google, SO, haskell.org so I could PR a Haskell equivalent but didn't find one.

This doesn't seem to work in p6 either? Actually now that I think about it I tried this as well when I was first developing the code. I guess because it's a constant we could just write it as a string and parse it using .base(16).

I think this is the best solution: https://github.com/LLFourn/Ouroboros-Explanation/commit/f145f03d4ec1cb2d8f6a48f6540960f24372a429


Feature request: Way to import/sync new actions+their bindings from an external project/library etc

The new Action based input system is conceptually really good and really powerful. But I noticed 3 problems.

Is there a way to migrate my actions from Unity project A to Unity project B? I tried copying actions.json to a new project and got loads of internal ID/reference errors until I reverted to default and manually added my actions from scratch. Which files do I have to copy for it to actually work?

There should be some kind of modularization to the actions jsons in a project so that you can bring in new actions from another utility project or library. Say I have my main project A, and a UI tool with 3 new bindings in project B. How do I import project B into project A?

After you import/sync actions, you should also be able to automatically import their key bindings without needing to manually assign them in the Binding UI. This should be possible if you know which files to copy over.

For right now you probably need to copy the whole SteamVR_Input folder. Modular action manifests / bindings are in the works.

I've implemented this functionality in the beta version of the plugin. Take a look and let me know if this works for your scenario: https://github.com/ValveSoftware/steamvr_unity_plugin/releases/tag/2.1b2

This is now in 2.2b1: https://github.com/ValveSoftware/steamvr_unity_plugin/releases/tag/2.2b1


MoveAndSlide only ever reports 1 collision maximum

No matter how many objects a CharacterBody3D is colliding with, after calling MoveAndSlide() the GetSlideCollisionCount function will only ever report 1 collision max. Here is an example:
https://github.com/user-attachments/assets/9e265444-8c88-421b-80b4-fcde38846286
I've intentionally no-clipped the character halfway in the ground, next to a moving platform. However, it always reports a single collision has happened.
Here's the code I used in the example:
// noclip position
var newPos = Position with
{
    X = Position.X + Velocity.X * (float)delta,
    Y = Position.Y + Velocity.Y * (float)delta,
    Z = Position.Z + Velocity.Z * (float)delta,
};

MoveAndSlide();

// noclip position
Position = newPos;

// draw collisions arrows
for (var i = 0; i < GetSlideCollisionCount(); i++)
{
    var collision = GetSlideCollision(i);
    var pos = collision.GetPosition();
    var normal = collision.GetNormal();
    DebugDraw3D.DrawArrow(pos, pos + normal, arrow_size: 0.05f, color: Colors.Green);
}

GetNode<Label>("Label").Text = "Collisions: " + GetSlideCollisionCount();

Actually, seems to be reproducible in the GodotPhysics3D engine so should be a Godot issue


Minor improvement for mmc

Summary

drivers/mmcsd: Rename mmcsd_read_csd to mmcsd_read_extcsd
drivers/mmcsd: mmcsd_sdinitialize should save csd register into priv->csd

Impact
code refactor only
Testing
ci

Rename mmcsd_read_csd to mmcsd_read_extcsd
Why?

Rename mmcsd_read_csd to mmcsd_read_extcsd

Why?

since CSD and EXTCSD is different register, the origin code uses the wrong name:

@xiaoxiang781216 - Thank you for the explanation. I would be much appreciated if your PR's answer the "Why" in the Title block.

commit message contain this info:
commit 6085b0be1b70c7fe8b19ecbe330b9675d2893bbe
Author: Xiang Xiao<EMAIL_ADDRESS>Date:   Tue Oct 17 23:32:52 2023 +0800

    drivers/mmcsd: Rename mmcsd_read_csd to mmcsd_read_extcsd

    since it really read extcsd register not csd register

    Signed-off-by: Xiang Xiao<EMAIL_ADDRESS>

Change to draft to wait the internal patch which support multiple emmc partition?


More Examples / documentation request

Hey,
I have been struggling for weeks to get a framework integrated with our application that supports Document Feeder scanning in a .net framework 4.8 app.
This is the first one I managed to get work (as there is no nuget package for NAPS2.SDK yet)
My one question is, is there any more documentation on naps2.WIA specifically?
It looks like there are events I can delegate for progress etc and just thought I would check if there are examples of that usage before I start diving into figuring everything out the slow way.

wrong location for this, my apologies.


Revert "Merge pull request #32628 from benlangmuir/sema-repeat"

This reverts commit 35eab3e3a8abc215c622862df139f97dc387d197, reversing
changes made to d5a549a9e49e7ac256f5599caa7b491c2fe7b4b4.
This caused an unexpected regression.
rdar://65554791

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

@swift-ci please smoke test

Failing Tests (1):
    Swift(windows-x86_64) :: stdlib/ForEachField.swift

Unrelated failure.

@swift-ci please smoke test Windows

@swift-ci please test Windows platform