-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Doc] Reworking README, adding LICENSE #3
base: main
Are you sure you want to change the base?
Conversation
bfb1516
to
deb9087
Compare
C:\> /path/to/new/virtual/environment/Scripts/activate | ||
``` | ||
```toml | ||
"emu-mps" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should add a warning that this will actually download the package from pypi, not install it editable from source. I don't actually see the point of having this paragraph, since the entire point of hatch is that it installs things in editable mode and manages the environments for you. Why install this package in a hatch env if all it does is give you the pypi version in an env with nothing else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're trying to standardize on hatch as a package manager, as it saves you from having to manage the virtual env yourself, which is already one less cause of headache.
I don't understand why users would expect it to be editable from source?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'm a bit unclear what specific workflow you're trying the explain for the user in the case of hatch.
They can use hatch to create an environment, and then use the pip install emu-mps
that you describe elsewhere in the README, for which you don't need to checkout the code and change the pyproject.toml
.
When the user does check out the code, I would expect that they'd want to install that specific version of the emulator, and potentially have it be editable, both of which will not happen if you modify the pyproject.toml
as you describe.
Maybe there is some alternative use-case that I'm missing somehow, but in the first case, the entire statement about modifying the pyproject.toml
can be removed, and in the second case, I'd expect some mention of the potentially undesirable behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My scenario is, for instance, quantum-evolution-kernel, which depends on emu-mps.
We specify the dependency in pyproject.toml
. No pip
involved. No venv
involved. hatch run
or hatch shell
will install the dependencies as needed. Or, for users who prefer uv
or poetry
, the local equivalents.
I believe that depending on emu-mps
will, by far, be the most common use case for emu-mps
. And I believe that users expect a package they depend on to be downloaded from pypi unless they take the necessary measures to ensure otherwise.
Old version was not compatible with Python 3.12.
Attempting to standardize the README and LICENSE across our new open-source releases.