[libre-riscv-dev] FHDLTestCase

Luke Kenneth Casson Leighton lkcl at lkcl.net
Sun Jun 7 00:45:43 BST 2020

On Sun, Jun 7, 2020 at 12:28 AM Yehowshua <yimmanuel3 at gatech.edu> wrote:
> But from what she told me, anything with `_` prefix
> has not guarantees of maintaining a stable interface.

correct.  and therefore the implications are: we must take a copy of
that code in order for it to be "maintained as a stable interface".

> So if we’ve been importing from `_`, that’s on us.

uh-huh.  and we just had to quotes take a copy of FHDLTestCase quotes.

and, because FHDLTestCase - which she wrote - uses nmigen._toolchain,
we must now quotes take a copy of _toolchain.py quotes.

... you see where that leads?

absolutely every single python nmigen developer must quotes take
copies of code quotes in order to guarantee that they have a stable
API to work with.

now, it *might* be the case that somebody notices that we have quotes
taken a copy of FHDLTestCase quotes and also quotes taken a copy of
_toolchain.py quotes.

they *might* use nmutil because of that, and thus avoid code-duplication.

however the much more likely scenario is that they will likewise take
copies of that code, maintain completely separate copies (effectively
hard forks).

the bottom line is that this, slowly, will demonstrate to whitequark
what the *actual* role and responsibility of being an open
collaborative software development maintainer is.  it's *not* to say
"this is not my responsibility, *i* declare - end of discussion - that
this is outside of scope of *my* project: if you try to use what *I
DECLARE* is private, that is YOUR problem", it's to be the gateway of
a *two-way* conversation.

i fully get that she is concerned about changing the API, and wants
the freedom and flexibility to change the internals.  python
unfortunately doesn't work that way.


More information about the libre-riscv-dev mailing list