[libre-riscv-dev] libre-riscv-dev Digest, Vol 23, Issue 16

[Samuel Falvo II]

On Fri, Jul 10, 2020 at 1:57 PM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:
> On Fri, Jul 10, 2020 at 9:47 PM Samuel Falvo II <sam.falvo at gmail.com>
wrote:
> *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
diagnostics output.

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
made progress!)

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