[feature] Please provide all methods in base ConanFile

Currently, ConanFile base class doesn’t provide methods which need to be overridden by user (for example package()), this makes writing mixins which add different steps to “common” flow harder.

Consider example:

class MixinHeaders(ConanFile):
    def package():
        super().package() # < See below
        self.copy("*.h")

class MixinLibraries(ConanFile):
    def package():
        super().package() # < See below
        self.copy("*.so*");

# Consumer:
class MyConan(ConanFIle):
    python_requires_extend = ["shared.MixinHeaders", "shared.MixinLibraries"]

As I understand, in order for this to work with arbitrary set of mixins all of them should call super().package() (something called MRO involved). The problem is that for one of them super() will be ConanFile which doesn’t have package() and recipe fails with AttributeError.

To work this around I had to use something like in every mixin:

try:
    super_package = getattr(super(), "package")
except AttributeError:
    pass
else:
    super_package()

which is bit ugly.

Maybe I get something wrong.

• I’ve read the CONTRIBUTING guide.

[memsharded]

I do agree that aggregation is to prefer. I just thought that since this mechanism is provided it should be used for these purposes. Was much skeptical myself about sharing python code as base classes when they were first introduced.

We introduced it because of high pressure by some users, but it is one of those features that we don’t love, because we feel that in general it adds little value (avoiding to type a couple of lines, 2 per method), but makes things more obscure (as you don’t know by reading a recipe if it is just missing a package_info() method, or it might be reusing an existing one from the base class, that you need to go elsewhere to read). So in that regard, it is fine that the feature is there, but we will try to limit its use as much as possible, and definitely try to limit it to simple cases.

[memsharded]

Sorry for late reply, was traveling…

No prob, thanks for the feedback.

Ok, the build_requires method made more sense, as it was not defined. In any case, if you can go explicit, we believe it is better in the midterm, even if not nasty super() tricks would be necessary, with multiple inheritance many different behaviors like order of evaluations, etc can easily bite you.

Thanks!