[libre-riscv-dev] libre-riscv-dev Digest, Vol 23, Issue 16
Samuel Falvo II
sam.falvo at gmail.com
Fri Jul 10 22:04:25 BST 2020
On Fri, Jul 10, 2020 at 1:57 PM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> On Fri, Jul 10, 2020 at 9:47 PM Samuel Falvo II <sam.falvo at gmail.com>
> *click*. that's it. note "nmigen-soc". you'll be able to see that
> in nmigen-soc's setup.py. (btw i cloned nmigen-soc in libre-soc.org
> and *removed* that hard dependency version number. don't use it
> though because it's a hard fork of nmigen-soc).
> you have a version of nmigen-soc installed (in the same virtualenv)
> that DEMANDS nmigen 0.1, and exactly and ONLY nmigen 0.1.
This is a completely unique virtualenv, so it shouldn't have happened.
But, what I suspect happened is I must have accidentally installed
nmigen-soc *first* before installing nmigen proper.
I've noticed (at least for me) that invoking `python setup.py develop` will
not cause an error if there's a dependency issue; `pip install -e .` will
at least issue an easily seen warning. Running setup.py directly seems to
just make assumptions about its environment. NOTE: I'm not suggesting one
should just stop using python setup.py develop; rather, if things seem
inexplicably askew, just try pip install -e . ; it seems to have better
I've uninstalled nmigen-soc and nmigen, then made sure to install nmigen
first, *then* nmigen-soc (both by way of setup.py develop), and it now
seems to work. Tests are reporting back OK so far (except for skipped
tests). (Update: now I'm getting a ton of other errors, but it's at least
Looking at the setup.py files in each, they seem to rely on some serious
black magic to auto-detect installed versions. I hate stuff like that.
Configuration management is precisely where you do *NOT* want black magic
to occur (IMHO).
Samuel A. Falvo II
More information about the libre-riscv-dev