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.

[joaotavora]

Thanks, @quicklisp. @hijarian, do you know of any particular break in backward compatibility when using this project (luismbo/stefil) vs using the stefil at quicklisp? Or were you just speculating?

[hijarian]

@capitaomorte I was speculating. I have quite a lot of first-hand experience with libraries being silently updated with BC breaking changes, so I assumed this outcome.

I see now that I was wrong. In this particular case it is actually good, because we probably can merge all three projects into single stefil if they are fully API-compatible. This would be the best IMHO.

[joaotavora]

I see now that I was wrong. In this particular case it is actually good, because we probably can merge all three projects into single stefil if they are fully API-compatible. This would be the best IMHO.

Hmmm, OK. You call the stefil package at quicklisp the "single stefil", right? So you're right, that leaves another option open, which is good.

But mind you I think hu.dwim.stefil is not compatible, I think, because of at least the package name and the defsystem name (and I think that's all). That could be fixed eventually with nicknames or some system-aliasing functionality which might exist somewhere in ASDF:-)

Then again, I personally am thinking of breaking some backward compatibility anyway, so the freedom of the renamed fork would be best in that respect.

Let's see what @luismbo says. IMHO forking is bad when it leads to duplicated/wasted effort, but given the current rate of investment in this lib, I think the benefits outweigh the risks.

[luismbo]

@attila-lendvai what are our chances regarding option 1?

[attila-lendvai]

stefil stands for Simple Test Framework in Lisp.

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.

i think that's one of the main features of stefil: it adds a defun* macro that defines functions so that they interact/ensure a runtime environment when invoked, but otherwise are the same as anything else wrt debugging, invoking, repl, etc. IOW, a super thin and simple layer that requires learning only a few new abstractions.

regarding merging with the current hu.dwim.stefil: my problem is that we have all this machinery for e.g. a more formal documentation, and the whole hu.dwim integration, etc... i don't think they are worthless, but then i'm also not actively working on lisp stuff these days to step in and promise to maintain that part.

other than that i wouldn't be against reworking fixtures and other things. the only thing i'm attached to regarding the stefil design is that tests are instrumented defuns, and that they return the test results as return value when invoked, which can then be inspected with specialized slime inspectors. and i also like that test suites are also defuns, that can even have a user-defined body but otherwise just call the nested tests.

i think the best is to fork on a new name, or alternatively i wouldn't mind obsoleting old stefil altogether. if you ask me i'll edit, or just hand over ownership, of any last traces of that old stefil (is there anything else besides http://common-lisp.net/project/stefil/ ?)

i can also promise to add pointers to the new project in hu.dwim.stefil documentation.

and re darcs hosting: you can ignore dwim.hu, these days even darcsweb.cgi stopped working there with chrome... but with darcs it's just patches and their own identities. last i checked there were some nice darcs hosting sites that seem to copy github features. but of course if you fork then it's up to you what you use.

[luismbo]

@attila-lendvai thanks for your input! I'm going to investigate option #2.

[luismbo]

@attila-lendvai (and @hijarian), regarding the "old stefil", I don't think removing http://common-lisp.net/project/stefil/ will particularly help. After we sort this out, I'll look into removing dependencies on "old stefil" (IIRC, it's probably just Babel) and then ask Xach to remove it from Quicklisp altogether.

[quicklisp]

Why remove it?

[attila-lendvai]

@luismbo, what i meant was that if you chose to stick to the stefil name, then you can just act as if it was a new version of stefil, only somewhat backwards incompatible. but progress by definition is incompatibility, which sometimes may need to reach the surface of the project also.

and if you so decide i can hand over the cl.net project.

[attila-lendvai]

@luismbo, as of fiveam: Stelian knew about stefil when he decided to use and maintain fiveam, so i don't think that he'll be especially open for the idea, but then things may have changed since then.

[luismbo]

@quicklisp, @attila-lendvai, I think having two projects named *stefil in quicklisp is needlessly confusing, don't you agree?

@attila-lendvai, having inspected FiveAM more closely, I think it'd take a fair amount of work to make it as nice as Stefil... so I'm unfortunately inclined towards option 3... :-(

[joaotavora]

Sooooo, naming time

1. "boris", because I thought "stefil" was for "Steffi Graf"
2. "alloallo", because http://stream1.gifsoup.com/view7/2926205/allo-allo-o.gif
3. ?

[quicklisp]

I think removing a project that people might be using is needlessly breaking. I don't think there's any confusion; I suspect when presented with two similarly-named libraries, one of which has a longer name, users choose the shorter one.

[joaotavora]

So here is a fork: http://github.com/capitaomorte/fiasco

I basically did a massive sed rename "stefil" -> "fiasco" and tweaked the README.md to mention Stefil and the original authors. @attila-lendvai can you check everything's OK with the licensing and so on.

@quicklisp what does one have to do or comply with to get one's package in the next quicklisp release? (apologies if this is answered somewhere else).

[attila-lendvai]

"can you check everything's OK with the licensing and so on"

@capitaomorte well, i reject the entire notion of intellectual property, that someone should be entitled to use violence to stop others from using knowledge... and i take your word for mentioning the origins of the project, so i'm sure we're just fine without much time wasted on this... :)

good luck with the new project!

[quicklisp]

@capitaomorte Create an issue at https://github.com/quicklisp/quicklisp-projects/issues - make sure your system definition has :description, :author, and :license info, too.

[attila-lendvai]

FTR, i've converted our darcs repo to git: https://github.com/hu-dwim/hu.dwim.stefil

[luismbo]

README updated 👍