[cl-dwim-devel] trouble with darcs repos

[Attila Lendvai]

> What I'm trying to figure out is whether the unit tests for babel, cl-l10n,
> and the like could use hu.dwim.stefil in place of legacy stefil with a few
> simple compatibility tweaks.  Alternatively, did you refactor stefil to
> include improvements that required changing the API?


not much has changed. iirc i've cleaned up the fixture stuff a bit,
but everything else should be compatible, maybe even fixtures are if
used though the with-fixture macro.


>> heh, i told Levy that hu.dwim.asdf is a very confusing name... :)
>
> Yes, it appeared that hu.dwim.X = X maintained by dwim.hu; but you're saying
> the pattern does not hold for asdf.  Is there a reason to maintain these
> tools separately from asdf?


well, yes.

partly because i don't want to get into the hopeless process of
convincing the ASDF mailing list about them, and it also contains
stuff like default values which are inherently specific to us and our
dwim.hu refactor.

also, it's on our TODO somewhere down to move to XCVB. in the lights
of that all asdf stuff is temporary... although what is not temporary?
but that's turning philosophical again... :)


>>> :stefil nickname to the :hu.dwim.stefil package and provide a stefil.asd
>>> that uses the normal ASDF?
>>
>> i think with the clarifications about hu.dwim.asdf you don't want this
>> anymore, do you?
>
> Not sure.  I now understand that hu.dwim.asdf can stay.  If a package
> nickname and stefil.asd would make hu.dwim.stefil a drop-in replacement for
> babel and cl-l10n, then I think that would be valuable.


i wouldn't do that because such nicknames can not be managed nicely in
CL's package system and its non-existent module system.

while in the current setup stefil and hu.dwim.stefil can live together
happily in the same image and people are free to delay the upgrade to
hu.dwim.stefil indefinitely.

although seems like we should write up something about it to clarify
the situation...


> How stable is all this stuff?  If you are freely refactoring the hu.dwim
> packages, then I will step back and wait for them to stabilize.


i can not directly answer this question, but i can say that if we see
how something could be done better, and if it gets high enough on the
TODO list, then we are not hesitating about a cleanup, even if it
involves non-backward compatible changes.

but on another note, all-in-all the hu.dwim stuff is stable enough to
run our site and our paying projects.

and while we don't care much about backwards compatibility, we do try
to make life easier for the users by branching and tagging at
important points...

the old version of our libs are all available in their original repos
which may even get some diverging fixes from the dwim.hu stuff. so,
tell me if you need something that would make your libCL maintainer's
life simpler, or better yet, just record any change you need in your
local darcs repo and darcs send it to us, or publish a repo link.

-- 
 attila