Which Stefil is a current definitive upstream?

[hijarian]

Hello!

This is not an issue about this particular codebase, but about this project as a whole.

Currently we have two "stefil" packages in the Quicklisp: stefil which is from Darcs repo at common-lisp.net and hu.dwim.stefil which is from Darcs repo at dwim.hu.

Now here is this "luismbo/stefil" project at GitHub. Can you please elaborate, whether this is a fork or a continuation of the previous work? Are these two "stefil" projects outdated?

[joaotavora]

Good quesiton. Let's call @attila-lendvai and @luismbo in on this.

From my part, I like the original stefil design a lot (apart from its support for fixtures perhaps) and would like to not offically fork it with another name. However, in our (mine and @luismbo's) current use of the library we find that the new features (package-bound suites and RUN-PACKAGE-TESTS) already brought into it simplify its learning curve, and perhaps want to introduce more.

I recall that @attila-lendvai had a couple other, non-conflicting, diverging commits in the darcs repo. May proposal is that we bring those in and make @attila-lendvai a contributor/admin of this project, and then make it official.

[attila-lendvai]

re quicklisp: to be honest, i don't understand why some people stick to the old stefil. there was a short period when hu.dwim.stefil, its successor, used to have more dependencies, but when people complained i cut back on the dependencies. today it's only alexandria and hu.dwim.asdf for the defsystem, although i think the latter could be gotten rid of easily by adding one more .asd file that doesn't integrate into our hu.dwim.foo scheme.

so, if you ask me the HEAD of the project is the latest hu.dwim.stefil here:

http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.stefil;a=summary

shamefully, that link doesn't seem to work with chromium. you can clone the repo like this:

darcs get http://dwim.hu/darcs/hu.dwim.stefil/

as of git and this github project: to this very day i still prefer the internal model and the workflow/UI of darcs, even with all its headaches. github is nice and all, and even some aspects of git itself are nice, but it smells of so much accidental complexity that it usually gives me a headache in short order when i deal with it...

as of this fork, it's the first time i hear about it. it's quite divergent from the start and it seems to have some non-trivial efforts invested in it. in spite of that, if it was in a darcs repo, i'd even fire up a darcs pull right now to pull over a few patches. but i will most probably not put much effort into working on this fork, so i give you my blessing on producing an opensource software that will serve you, and hopefully others, better!

hu.dwim.stefil was ripe for a clean-slate rewrite anyway. essentially it's still the first proof of concept where we tried out my vision of a test framework that integrates into normal development/debugging.

and if i'll ever get back to full-time CL hacking, then i may even switch to this fork myself and ask for that admin bit, or just clone it with a power-user hat on... :)

[hijarian]

OK, so I will summarize.

1. This project is a fork.
2. "Official" stefil is a hu.dwim.stefil but it's probably not maintained any more.
3. :stefil system installable from quicklisp is obsolete.
4. It's overall better to use this project as it's actively maintained now. However, hu.dwim.stefil probably is feature-complete too in a sense that there's nothing to "fix" or add to there (I am not sure about it).

[attila-lendvai]

yep, that's about right as far as i'm concerned, with the addition that 4) is rarely the case with software... ;)

[joaotavora]

@attila-lendvai, thanks for clearing this up. I honestly thought @luismbo had mentioned to you that we were using and working on stefil, but maybe I messed up, sorry.

So, if I understand correctly: If our goals were to get this project both hosted on github and available on quicklisp the alternative we have is to "properly" fork it, i.e. give it another name, crediting you and the authors of the previous effort in full, of course. Any objections?

[hijarian]

Naming is a headache, by the way. If you are to rename this project we then will have three flavors of stefil in quicklisp. Maybe it will be better if you rename it to something completely different.

Or @xach will agree to purge at least that obsolete "stefil" from the libraries and replace it with this particular fork using same name. We'll throw the backwards compatibility out of a window this way, though.

[attila-lendvai]

honestly thought @luismbo had mentioned to you that we were
using and working on stefil, but maybe I messed up, sorry.

well, it may very well be that at one point i knew about this, even discuss it, but then it apparently got purged from my mind by other stuff overflowing it... that happened before.

either way, no hard feelings!

[joaotavora]

either way, no hard feelings!

@attila-lendvai, none taken. Anyway just to summarize this, in my opinion this problem should be named something else, something very distinct as @hijarian suggests, and development should continue in github.

Now for names... any suggestions? Where did stefil come from?

[luismbo]

Here are the possible outcomes of this fork, by decreasing order of personal preference:

1. we merge back into the official hu.dwim.stefil and remove the old stefil from Quicklisp. (This would imply @attila-lendvai & co. agreeing with our changes, namely define-test-package and it seems that it would also imply moving to github or similar. I also like darcs, but the hosting at dwim.hu is a bit of a PITA by comparison. :-()
2. we port our features onto sionescu/fiveam instead. One of the major API differences is that test names are in their own namespace rather than the function namespace. After wanting to name unit tests after the functions they test, I'm not so sure it's a good idea to reuse the function namespace anymore.
3. we rename this fork and move on.

I see this last one as a last resort, really...

[quicklisp]

A new name is the best for people who are using one or more of the existing stefils now. Their programs will continue to work even after they update their supporting libraries.

[joaotavora]

@luismbo, don't get me wrong, I also see the fork as a last resort, but I also happen to think it is pragmatic right now and doesn't exclude your option 2. in the future, or even 1 by that matter!

Regarding 1 (merging back to dwim.hu) remember that, last we talked, there were other non-trivial changes in the pipeline, such as ditching fixtures and using clos hierarchies for setup/teardown. Those would have to be discussed.

Regarding 2 (merging with FiveAM) perhaps it is a good idea. I haven't seen FiveAM enough to know its advantages.

• Aren't you underestimating the differences between the two projects?
• Who would put in this merging effort? You? I could help if there is sufficient enthusiam from others and someone convince me of the advantages.
• I personally do like tests in the function namespace, and a some of my code already depends on it (perhaps even some of yours). So for me this is kind of a deal breaker.

@quicklisp, I agree forking with a new name is probably the safest choice, though in principle, the changes we have made do not break backward compatibility from the original :stefil. I haven't audited the API though.

[quicklisp]

Oh, ok, that's good to know. I had the impression that the changes were not compatible.

[joaotavora]

Oh, ok, that's good to know.

I did say "in principle" :-)

I had the impression that the changes were not compatible.

Where from, btw?

[quicklisp]

From:

Or @xach will agree to purge at least that obsolete "stefil" from the libraries and replace it with this particular fork using same name. We'll throw the backwards compatibility out of a window this way, though.

[quicklisp]

I am generally against compatibility defenestration.