ftalbrecht commented 5 years ago

I probably broke stuff. In particular, codegen.py and cmake.py now reside in dune.xt.common (not dune.xt), and I do not know where these are used. Also empty is now not a module any more, the test simply imports the so directly, and I am not sure if that is what you had in mind, @renefritze!

renefritze commented 5 years ago

codegen and cmake are used in all of the python template test setups in all dependent modules. Maybe a softer transition would be good?

ftalbrecht commented 5 years ago

codegen and cmake are used in all of the python template test setups in all dependent modules. Maybe a softer transition would be good?

I just kept them below dune/xt/ for now.

codecov[bot] commented 5 years ago

Codecov Report

Merging #191 into master will decrease coverage by 1.24%. The diff coverage is n/a.

Impacted Files	Coverage Δ
dune/xt/common/type_traits.hh	`43.37% <0%> (-6.63%)`	:arrow_down:
dune/xt/common/parameter.hh	`45.32% <0%> (-5.81%)`	:arrow_down:
dune/xt/common/logstreams.cc	`76.43% <0%> (-4.25%)`	:arrow_down:
dune/xt/common/memory.hh	`67.81% <0%> (-3.3%)`	:arrow_down:
dune/xt/common/fixed_map.hh	`87.59% <0%> (-2.75%)`	:arrow_down:
dune/xt/common/validation.hh	`85.07% <0%> (-2.46%)`	:arrow_down:
dune/xt/common/string_internal.hh	`71.63% <0%> (-1.63%)`	:arrow_down:
dune/xt/common/fvector.hh	`98.36% <0%> (-1.13%)`	:arrow_down:
dune/xt/common/float_cmp_internal.hh	`92.49% <0%> (-0.54%)`	:arrow_down:
dune/xt/common/math.hh	`95.2% <0%> (-0.4%)`	:arrow_down:
... and 9 more

ftalbrecht commented 5 years ago

K, so

I leave the use of guarded_import as it is
look into importing dependent modules within the .so (so each .so is functional on its own)

where the latter means guarding every m.def by a try/catch block.

renefritze commented 5 years ago

where the latter means guarding every m.def by a try/catch block.

I don't follow. Why would you need that?

ftalbrecht commented 5 years ago

where the latter means guarding every m.def by a try/catch block.

I don't follow. Why would you need that?

That was a bit too unspecific, I guess. We will have to guard classes, not necessarily functions.

Well, take functions for instance. If we import the dune.xt.functions._function_interface in each .so of every function, the bindings of the interface are executed multiple times, hence duplicate names, hence guards. Since we do not know in general who will depend on an .so (which is one of the points of not having to determine a global module order, I think), we will always have to use guards...

renefritze commented 5 years ago

I'm trying to understand what issue you think with importing the same module in multiple bindings code happens.

Have a look at https://github.com/dune-community/import-test/tree/master/python/dune/xt/imptest

First defines a class Second and third import the module in their bindings code while defining a derived class.

This works without error afaict.

🐳[~/master_xt_clion/import-test] ./run-in-dune-env ipython

In [1]: import dune.xt.imptest                                                                                        

In [2]: import dune.xt.imptest.second                                                                                 

In [3]: import dune.xt.imptest.third

Maybe you can modify the example so it creates the situation you're thinking of and then fails?

ftalbrecht commented 5 years ago

Superseeded by https://github.com/dune-community/dune-xt-common/pull/193 due to github issues.

dune-community / dune-xt-common

[python] move to common/ subdir #191

Codecov Report