You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is useful to have easy access to commands like briefcase new in order to start new projects, but some commands, such as briefcase dev, should only be run from a project-specific virtual environment.
Describe the solution you'd like
Have a heuristic to determine whether sys.executable is in a shared environment (pipx, system Python, other possibilities?), and, before installing packages in such an environment, either prompt the user to continue, or block the install outright.
Describe alternatives you've considered
A shell script to do something like pipx run briefcase new. This wouldn't require any changes to briefcase, but it would require work downstream.
Additional context
This is the only thing unique to #1733 that is worth discussing further at the moment.
The text was updated successfully, but these errors were encountered:
I'm going to close this, on the basis that I don't believe it makes any sense for Briefcase to do this. pip doesn't provide warnings like this; as currently implemented, briefcase dev fills almost exactly the same niche of the ecosystem as pip. The closest analog of something like this would be the behavior implemented by PIP_REQUIRE_VIRTUALENV - a setting which I believe Briefcase will honor.
This entire line of discussion seems to have emerged from a fundamental misunderstanding about what Briefcase is, how it works, and the assumption that it can be safely used with pipx. That is the root problem here. There is nothing in the Briefcase documentation that recommends the use of pipx; everything in the tutorial actively encourages you to create a project-specific virtual environment, and install Briefcase in that environment. I guess we could add a "don't install Briefcase with pipx" instruction to the docs; but I'm not sure where we'd put that instruction in the docs so that the people who need to read that would ever actually see it. Plus - Briefcase will work with pipx - it just dirties the virtual environment - which is... exactly how Briefcase operates by design.
FWIW, there was another approach mentioned #1733 - using an isolated environment for the dev app. I've logged that as #1735 for posterity, but I'm not 100% sold on whether that's something we should do.
What is the problem or limitation you are having?
It is useful to have easy access to commands like
briefcase new
in order to start new projects, but some commands, such asbriefcase dev
, should only be run from a project-specific virtual environment.Describe the solution you'd like
Have a heuristic to determine whether
sys.executable
is in a shared environment (pipx, system Python, other possibilities?), and, before installing packages in such an environment, either prompt the user to continue, or block the install outright.Describe alternatives you've considered
A shell script to do something like
pipx run briefcase new
. This wouldn't require any changes to briefcase, but it would require work downstream.Additional context
This is the only thing unique to #1733 that is worth discussing further at the moment.
The text was updated successfully, but these errors were encountered: