Re: Changing a cl-defstruct definition in a published package

["João Távora" <joaotavora@gmail.com>]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 2018-07-13 13:01, João Távora wrote:
>> There's no way to fix the problem now without breaking backward
>> compatibility because by now B's use of your accessor has been
>> compiled into something that probably looks like an aref into an
>> array.
>
> Indeed, I suspected as much…
>
>> So if you change your object layout in A, you break a compiled B.
>
> Right, but I can't afford that.  Do you have ideas on workarounds?
> Some other source-based package managers recompile dependencies on
> update.  IIUC, package.el doesn't do that.  Maybe it should?  But it
> sounds like a lot of extra work.
>
> What would you do? I don't think breaking all packages that depend on
> FlyCheck is a valid option :/

You wouldn't be breaking the packages totally, you would be breaking the
compiled code.  You could argue that it's package.el's responsibility to
notice, knowing the dependency chain, that some things need to be
recompiled if a dependency changes upstream.  Like Make does, basically.
But arguing of course won't solve the immediate problem you have at
hand.

I don't know what you're trying to do, but the only way is not to change
the object layout, and to guarantee that the value that the user
packages are looking for is indeed found there at the right time.  A
potentially horrible amount of hookage awaits you, but you could at
least also add your new feature/change and get rid of the hacks later.

João