One other thing - the base for this still requires dnf and hawkey. the runner requires rpm_utils so I didn't see a point in moving that to extensions/fedora since the runner will be undergoing some pretty big changes soon anyways.

If we go forward with this, it'd be after the big rename/refactor but I wanted to write against a stable base so this is against current disposable-develop

bump/ping

Was hoping for some feedback and thoughts on the general approach - whether this is worth pursuing or not. Now that f23 beta's been released, was hoping folks might have more time to look at it

Ignoring that the rpm_utils module isn't being refactored out yet, the approach looks pretty solid. It looks like a solid foundation to develop a useful, distro-agnostic test framework. With the split of the module out, is it now possible to use libtaskotron in a purely Python 3 environment?

I haven't run or studied the code in detail but the approach overall looks good to me.

The code in exthook and changes in runner are very difficult to read and (I suppose) a hell to debug.

Why exactly do we need to use this? I thought the split would be easy, keep everything as it is (shuffle the files into dirs if needed), and just package them into separate RPM files. Add a bit of inconvenient logic "import foo or do something else". I don't understand much the reasons why moving stuff into /usr/share is better, can you expand on that? The module loader is ugly and it reminds me of autotest, which placed modules into completely unexpected places and then used dark magic when rewriting the imported names using arcane rules. I hated working on it, because I spent considerable time just locating a particular module on disk. (They said they were trying to get away from that with avocado).

Can't we simply put everything into libtaskotron/ext/ and then install it into the same location in site-modules? If multiple setup.py files are needed for that, OK, no big deal, we have doit to do it :-) I don't understand the other concerns, please explain. Thanks.

Why exactly do we need to use this? I thought the split would be easy, keep everything as it is (shuffle the files into dirs if needed), and just package them into separate RPM files. Add a bit of inconvenient logic "import foo or do something else". I don't understand much the reasons why moving stuff into /usr/share is better, can you expand on that? The module loader is ugly and it reminds me of autotest, which placed modules into completely unexpected places and then used dark magic when rewriting the imported names using arcane rules. I hated working on it, because I spent considerable time just locating a particular module on disk. (They said they were trying to get away from that with avocado).

I was trying to avoid putting the code into different repositories and needing more setup.py files in a different namespace and this allows for directives in the extension as well. I also wanted to create an actual extension system instead of splitting our code up into subpackages and calling it "extensions" that only we can use.

Complexity-wise, I didn't see a whole lot of difference between loading namepace-ish extensions (doing taskotron_ext.* modules or something like that) and having a single location from which we could import extension code and directives.

Can't we simply put everything into libtaskotron/ext/ and then install it into the same location in site-modules? If multiple setup.py files are needed for that, OK, no big deal, we have doit to do it :-) I don't understand the other concerns, please explain. Thanks.

That's how Flask used to do it but that has changed. I didn't get to the bottom of exactly why that changed other than it was swallowing exceptions and I figure they wouldn't have made a change that broke existing Flask extensions if there wasn't a good reason for it.

I also worry about having one common directory in site_packages that a bunch of stuff is getting installed into after bypassing any of python's mechanisms for installation - it smells like something that would cause problems sooner or later.

I'll see if I can come up with a different way of doing extensions

In D581#11613, @tflink wrote:

I was trying to avoid putting the code into different repositories

I'm sorry, I'm really slow - why would different repositories be needed?

I also wanted to create an actual extension system instead of splitting our code up into subpackages and calling it "extensions" that only we can use.

What should this extension system be able to do? Because I thought we wanted to do the former, a split to subpackages. Who else should be able to use the extensions? Some other library, instead of importing libtaskotron and using it through it?

That's how Flask used to do it but that has changed. I didn't get to the bottom of exactly why that changed other than it was swallowing exceptions and I figure they wouldn't have made a change that broke existing Flask extensions if there wasn't a good reason for it.

I'm not familiar with Flask, but that commit seems to rework is_important_traceback() method which sounds relevant to the commit title - maybe a different way of importing modules is just a byproduct?

I also worry about having one common directory in site_packages that a bunch of stuff is getting installed into after bypassing any of python's mechanisms for installation - it smells like something that would cause problems sooner or later.

So, are you saying we can't use python standard install mechanism (setup.py) to install files foo.py, bar.py into /usr/share/python2.7/site-packages/libtaskotron/ext/common and then a different setup.py to install baz.py into the same directory? Or am I completely misunderstanding this?