move designSpaceDocument to fontTools.designspace?

[anthrotype]

Erik, how about we move the designSpaceDocument/__init__.py module into a new fontTools.designspace module (or if you prefer camelCalse, fontTools.designSpaceDocument)?

Only the generic part, not the ufo specific one (for now at least, until we also have a fontTools.ufoLib).

You'll still be the benevolent dictator of course... ;)

[anthrotype]

https://github.com/fonttools/fonttools/issues/911

[LettError]

• Name: shorter might be better.
• So to be clear we can separate the ufoProcessor module from the code that's going to fontTools? I'd prefer that because I probably need that thing more that you do. I can make it a separate package.
• Is there a preferred way to indicate that the main repository has moved?

[anthrotype]

Name: shorter might be better.

how about fontTools.designspaceLib (dsLib?) for consistency with ttLib, varLib, ufoLib, etc.?

we can separate the ufoProcessor module from the code that's going to fontTools?

yes, fontTools doesn't know about ufo (yet).

I probably need that thing more that you do

also we would like something like that -- for example in glyphsLib where we convert from *.glyphs to designspace + UFOs. We currently use mutatormath for that.

Is there a preferred way to indicate that the main repository has moved?

just a big notice in bold at the top of the README, I guess

[belluzj]

from *.glyphs to designspace + UFOs. We currently use mutatormath for that.

...and we're moving to use designspaceDocument instead, as done in the roundtrip PR. So a class like ufoProcessor would probably be useful to glyphsLib in the near future. I have currently written a very thin subclass of DesignSpaceDocument to allow keeping a reference to an in-memory defcon.Font instead of a pathname in SourceDescriptor, and I will soon have to add functionality similar to ufoProcessor.

Maybe once the move to fonttools is done for the basic DesignSpaceDocument, we can discuss the glyphsLib usecase for something like ufoProcessor, and if we find that it's a generic enough use-case, we could put the supporting class into fonttools as well?

[behdad]

This is done now. I need to review it a bit and possibly change API, but after that we can call it moved.