-
Notifications
You must be signed in to change notification settings - Fork 175
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
setup.py: add "wheel" to setup_requires #349
Conversation
Fixes problem when installing into a python venv created with $ python3 -m venv my_env See m-labs/nmigen#323
Do you know why this dependency is necessary? It looks like Python is trying to build a wheel here, but the wheel library doesn't exist, which seems like a strange situation. Does this only happen if you install nmigen from git in virtualenv, and not otherwise? |
Codecov Report
@@ Coverage Diff @@
## master #349 +/- ##
=======================================
Coverage 82.64% 82.64%
=======================================
Files 35 35
Lines 5948 5948
Branches 1208 1208
=======================================
Hits 4916 4916
Misses 868 868
Partials 164 164 Continue to review full report at Codecov.
|
The default __repr__() from typing.NamedTuple does not include the module name, so the replacement (which uses the preferred syntax for specifying these shapes) doesn't either.
Also known as word_select().
Before this commit, selecting a part that was fully out of bounds of a value was correctly implemented as a write to a dummy wire, but selecting a part that was only partially out of bounds resulted in a crash. Fixes #351.
Such wires are likely to trigger pathological behavior in Yosys and, if applicable, other toolchains that consume Verilog converted from RTLIL. Fixes #341.
By default, if an operation produces an undefined value (a Jinja2 concept that corresponds to Python's KeyError, AttributeError, etc) then this value may be printed in a template, which is a nop. This behavior can hide bugs. This commit changes the Jinja2 behavior to raise an error instead of producing an undefined value in all cases. (We produce undefined values deliberately in a few places. Those are unaffected; it is OK to use several kinds of undefined values in one Jinja2 environment.) Fixes #337.
This does not belong in |
I am not able to reproduce either:
|
I think this is a difference between |
I created the environment with Either way, there is nothing in nmigen that explicitly requires |
@FFY00 - Your on Arch Linux right? I think the problem is with how Ubuntu / Debianism mangles Python packages. Is |
Then it would be a Debian bug. No, |
The default __repr__() from typing.NamedTuple does not include the module name, so the replacement (which uses the preferred syntax for specifying these shapes) doesn't either.
Also known as word_select().
Before this commit, selecting a part that was fully out of bounds of a value was correctly implemented as a write to a dummy wire, but selecting a part that was only partially out of bounds resulted in a crash. Fixes #351.
Such wires are likely to trigger pathological behavior in Yosys and, if applicable, other toolchains that consume Verilog converted from RTLIL. Fixes #341.
By default, if an operation produces an undefined value (a Jinja2 concept that corresponds to Python's KeyError, AttributeError, etc) then this value may be printed in a template, which is a nop. This behavior can hide bugs. This commit changes the Jinja2 behavior to raise an error instead of producing an undefined value in all cases. (We produce undefined values deliberately in a few places. Those are unaffected; it is OK to use several kinds of undefined values in one Jinja2 environment.) Fixes #337.
Fixes problem when installing into a python venv created with $ python3 -m venv my_env See m-labs/nmigen#323
I am seeing the problem on Ubuntu. Installation is successful with "wheel" in extra_requires rather than setup_requires. One aspect of this problem is that wheel appears to be installed by default with virtualenv, but not with venv. |
How does your Can you post the exact commands to reproduce? It seems like you messed up the history by doing a merge. Can you look at reflog, do a hard reset to a previous state and then rebase on master? This should result in a clean git tree with just one commit on top of master. Let me know if you need help with the commands. |
what version of ubuntu and python3? |
@alanvgreen I believe you are hitting an issue with the way Debian ships Python packages. If you install |
@ohsix : from the bug report
|
Fixes problem when installing into a python venv created with $ python3 -m venv my_env See m-labs/nmigen#323
Fixes problem when installing into a python venv created with $ python3 -m venv my_env See m-labs/nmigen#323
@FFY00 Thanks for your kind offer, I think I managed to straighten out my pull request. Let me know if not. Here is a repro:
If I then attempt to
I don't know what to make of that - I wouldn't trust the installation. Looking at https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-extras-optional-features-with-their-own-dependencies I'm not sure why extras_require is the right thing to use here. What did you have in mind? |
@whitequark It turns out that I already had python3-wheel installed. I can't recall whether I explicitly installed it before - it may have been a dependency of something else, but very likely it was something I tried while working through my problems. At this stage, I'm quite happy for the resolution of this PR to be "use virtualenv, not venv" :) |
It looks like the documentation for venv describes it as deprecated since 3.6. Is that right? |
only the |
@alanvgreen If you're happy using virtualenv then I suggest closing this, since it seems very hard to reproduce. If someone manages to find a good solution here I'm happy to merge it as well. |
Yup. Closing, thanks all! |
@alanvgreen try
|
@graingert Yes, that seems to work for me:
|
@alanvgreen Thanks for confirming! There are some issues with #358 that prevent merging it in the short term, but I'll make sure that this is fixed at some point. For now, please use |
This is necessary to be able to install nMigen into a virtualenv that does not have `wheel` installed in certain cases. See #349.
This is necessary to be able to install nMigen into a virtualenv that does not have `wheel` installed in certain cases. See #349.
@alanvgreen I fixed this properly in 7fca037. |
Fixes problem when installing into a python venv created with
$ python3 -m venv my_env
See m-labs/nmigen#323