From: Samuel Falvo II <sam.falvo@gmail.com>
To: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Cc: Libre-RISCV General Development <libre-riscv-dev@lists.libre-riscv.org>
Subject: Re: [libre-riscv-dev] libre-riscv-dev Digest, Vol 23, Issue 16
Date: Fri, 10 Jul 2020 14:04:25 -0700
Message-ID: <CAEz=sokZ0B0v8crmtK0=jgHkf9TxSFHoUp29APW-DoyS0Pno1g@mail.gmail.com> (raw)
In-Reply-To: <CAPweEDwtHRS1W9xanjt8jqf4-Abg=kLBoL3VJJ_DgnaK=hHbiA@mail.gmail.com>
On Fri, Jul 10, 2020 at 1:57 PM Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:
> On Fri, Jul 10, 2020 at 9:47 PM Samuel Falvo II <sam.falvo@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
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
next prev parent reply index
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1.1594401220.8323.libre-riscv-dev@lists.libre-riscv.org>
2020-07-10 20:46 ` Samuel Falvo II
2020-07-10 20:56 ` Luke Kenneth Casson Leighton
2020-07-10 21:04 ` Samuel Falvo II [this message]
2020-07-10 22:33 ` Luke Kenneth Casson Leighton
2020-07-10 22:50 ` Jacob Lifshay
2020-07-10 22:58 ` Luke Kenneth Casson Leighton
2020-07-10 23:07 ` Luke Kenneth Casson Leighton
2020-07-11 0:35 ` Jacob Lifshay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAEz=sokZ0B0v8crmtK0=jgHkf9TxSFHoUp29APW-DoyS0Pno1g@mail.gmail.com' \
--to=sam.falvo@gmail.com \
--cc=libre-riscv-dev@lists.libre-riscv.org \
--cc=lkcl@lkcl.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Libre RISC-V Mailing list Archives (accessible via public-inbox)
Archives are clonable: git clone --mirror https://inbox.libre-soc.org/libre-riscv-dev
Example config snippet for mirrors
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git