is compatibility with defcon still needed or used by anyone?

[anthrotype]

ufo2ft started as a fork of ufo2fdk and we kept compatibility with the defcon API even as we created a lightweight alternative in ufoLib2. ufo2ft's test suite runs against both ufoLib2 and defcon, and we make sure never to import directly either of the two in the ufo2ft library code, so that one can compile fonts by injecting either ufoLib2.Font or defcon.Font objects as input, without strictly requiring either of two (at least one is still implicitly required).
This works, but it introduces some extra complexity in the code because the two APIs are not exactly identical.
fontmake, the main client of ufo2ft, already only uses ufoLib2 Fonts, and that's fine for a CLI tool.

Now I'm wondering if anyone out there wants to keep using ufo2ft for compiling defcon Font objects and would prefer if ufo2ft kept supporting this particular use case.

(this is just a question, I'm not actually planning on dropping support any time soon)

Do you know if e.g. Robofont (which I think it's built on top of defcon) uses ufo2ft at all and compiles defcon Fonts with it?

/cc @typemytype @typesupply @LettError @justvanrossum

[typesupply]

This works, but it introduces some extra complexity in the code because the two APIs are not exactly identical.

Are the differences listed somewhere? Perhaps the solution is to reduce the complexity inside of ufo2ft by having a common API.

[anthrotype]

Are the differences listed somewhere?

unfortunately not

Perhaps the solution is to reduce the complexity inside of ufo2ft by having a common API.

maybe, but this still adds some amount of friction.

That's why I'm interested to know if anybody is actually interested in ufo2ft defcon support.

[typesupply]

maybe, but this still adds some amount of friction.

Hmmmm. Could ufo2ft have a published protocol that objects could follow?

That's why I'm interest to know if anybody is actually interested in ufo2ft defcon support.

I'm pretty sure that I have seen defcon based code using ufo2ft. I haven't used it myself, but I haven't written any substantial binary code in a while. (That may change in the near-ish future.)

[anthrotype]

Could ufo2ft have a published protocol that objects could follow?

it would be nice indeed. It basically is the minimum common denominator between ufoLib2 and defcon, plus we have some additional code to handle some differences that can't be reconciled (e.g. like Glyph.name attribute being read-only in ufoLib2 and can only be set in the default constructor or ufoLib2.Font default constructor not taking a path as first argument but with Font.open(path) alternative constructor and some others)

[typesupply]

(e.g. like Glyph.name attribute being read-only in ufoLib2 and can only be set in the default constructor or ufoLib2.Font default constructor not taking a path as first argument but with Font.open(path) alternative constructor and some others)

I think it would be fine to add these to defcon.