Circular dependencies: Rinohtype > fonts > Rinohtype

[hartwork]

Hi!

rinoh-typeface-texgyreheros depends on rinohtype while rinohtype depends on rinoh-typeface-texgyreheros. Please resolve the unnecessary circular dependency, e.g. as done by rinoh-typeface-texgyreheros-0.1.1-circular.patch.

Thanks and best, Sebastian

PS: All other rinohtype fonts I have seen so far have the same issue.

[brechtm]

The fonts depend on rinohtype since they make use of classes defined in the rinohtype package. The rinohtype distribution in turn depends on a number of fonts because they are used in the standard style sheets.

This doesn't seem to pose a problem for pip. Does this cause trouble when packaging rinohtype?

[hartwork]

I overlooked that the font packages actually have code; interesting.

It doesn't seem to be a practical problem to pip but if you were importing rinohtype in fonts`setup.py, it would be. The pip output

# pip3 install rinohtype
[..]
Installing collected packages: rinoh-typeface-dejavuserif, docutils, rinoh-typeface-texgyreheros, commonmark, recommonmark, purepng, rinoh-typeface-texgyrepagella, rinoh-typeface-texgyrecursor, rinohtype
[..]

tells me that pip tries to install dependencies before dependees as expected. It doesn't seem to care much about detecting circles.

If we distinguish buildtime from runtime dependencies as some distributions would, we have:

• fonts have buildtime and runtime dependency on rinohtype
• rinohtype has a runtime dependency on fonts, only

To get from an empty system to cuntional rinoh the steps would need to be:

0. empty system
1. install rinohtype, not 100% runnable yet
2. install fonts, build deps satisfied by now
3. run rinohtype

On systems that do not go 100% on that distinction/separation, either some dependency has to be dropped as a workaround to break the cycle or rinohtype just won't be installable; for example:

# sudo emerge -1 --tree app-text/rinohtype
[..]
[nomerge       ] app-text/rinohtype-0.3.1::betagarden  PYTHON_TARGETS="python3_4 python3_5" 
[ebuild  N     ]  dev-python/rinoh-typeface-texgyrecursor-0.1.1::betagarden  PYTHON_TARGETS="python3_4 python3_5 python3_6" 0 KiB
[ebuild  N     ]   app-text/rinohtype-0.3.1::betagarden  PYTHON_TARGETS="python3_4 python3_5" 0 KiB

Total: 2 packages (2 new), Size of downloads: 0 KiB

 * Error: circular dependencies:

(app-text/rinohtype-0.3.1:0/0::betagarden, ebuild scheduled for merge) depends on
 (dev-python/rinoh-typeface-texgyrecursor-0.1.1:0/0::betagarden, ebuild scheduled for merge) (runtime)
  (app-text/rinohtype-0.3.1:0/0::betagarden, ebuild scheduled for merge) (buildtime)

What I would suggest for a clean solution is extracting a new package for the code that fonts depend on and have both the fonts and rinohtype pull it in. Fonts then no longer depend on rinohtype and there is no cycle. Maybe it's not superurgent to fix right now, but please keep it in mind so things don't get worse.

What do you think?

[brechtm]

If we distinguish buildtime from runtime dependencies as some distributions would, we have:

fonts have buildtime and runtime dependency on rinohtype rinohtype has a runtime dependency on fonts, only

What happens during the build phase for Python packages? I suppose it's just copying files for pure-Python packages like rinohtype?

What I would suggest for a clean solution is extracting a new package for the code that fonts depend on and have both the fonts and rinohtype pull it in. Fonts then no longer depend on rinohtype and there is no cycle. Maybe it's not superurgent to fix right now, but please keep it in mind so things don't get worse.

I'd rather not split off the font code to a separate package. I think it would be better to include the standard fonts in the rinohtype distribution instead. But then they would always need to be upgraded together, which doesn't make sense since the fonts will rarely get updated.

Do the dependencies in Linux packages need to map 1-1 to the Python distributions? You could simply remove the rinohtype dependency from the fonts. Or you can include the fonts in the rinohtype package.

P.S. Thank you for creating rinohtype Gentoo packages!

[hartwork]

What happens during the build phase is whatever ./setup.py install ... wants to do :)

Please don't include the fonts with rinohtype, let alone for licensing reasons and what to put into setup.py for licenses then.

I see why you don't want to split the fonts code into a separate package. Maybe you can resolve that code altogether by making the font packages serve static information (say JSON) for what seems to be a single function call now. Looking at https://github.com/brechtm/rinoh-typeface-texgyreheros/blob/master/rinoh_typeface_texgyreheros/__init__.py#L16 that one could well be static and it wouldn't be hard to transform. Do you have any font packages that do more complex stuff in code?

[brechtm]

All of the font packages only instantiate a Typeface instance. So, no, there aren't any that do more complex stuff.

In the future, I want to also support system-installed fonts. The Typeface instance will have to be created automatically. The same method could be used to remove the code from the font packages, I suppose. But for now, how about the suggestions I made in my last paragraph?

[hartwork]

TL;DR: Workarounds for status quo work, none of them is clean, clean approaches need changes in code/structure (if a clean solution is our goal).

On the suggestions you made:

a) I think it would be better to include the standard fonts in the rinohtype distribution instead.

Please don't, addressed above.

b) You could simply remove the rinohtype dependency from the fonts.

That's the current workaround. Good enough to fix the current symptoms, not clean.

c) Or you can include the fonts in the rinohtype package.

It won't make a "pretty" package, e.g. the version number will only reflect rinohtype's versions or five versions have to be flattened into one. Also people would need to run more code and replace more files than needed if only one of these five changes.

[brechtm]

There is nothing inherently unclean about the circular dependency. Pip (and even easy_install) handle them without issues. So it could be argued that limitations in Gentoo Portage are in fact the problem here.

The workaround of dropping the rinohtype dependency for the font packages doesn't seem too bad for now. Let's revisit this when rinohtype supports loading system fonts (and font distributions can be data-only packages).

[hartwork]

There is nothing inherently unclean about the circular dependency. Pip (and even easy_install) handle them without issues. So it could be argued that limitations in Gentoo Portage are in fact the problem here.

While I agree that it would be cool if portage would not require runtime-only dependencies before installation, pip only supports that case because it has a poor dependency resolver; install_requires (as in "required before installation of self") with a true circle cannot be met by something that does care.

[brechtm]

install_requires (as in "required before installation of self")

While the name might make one think otherwise, install_requires lists run-time dependencies. From the setuptools documentation:

install_requires A string or list of strings specifying what other distributions need to be installed when this one is.

There is also setup_requires, for "build-time" dependencies:

setup_requires A string or list of strings specifying what other distributions need to be present in order for the setup script to run. setuptools will attempt to obtain these (even going so far as to download them using EasyInstall) before processing the rest of the setup script or commands. This argument is needed if you are using distutils extensions as part of your build process; for example, extensions that process setup() arguments and turn them into EGG-INFO metadata files.

[hartwork]

I see, thanks.