repository messes with import hooks

[oamg]

repository messes with import hooks

[bocekm]

@pemensik, what library are you trying to test? leapp-repository shared or actor library? If so, in such a library you need to include leapp framework python modules.
If you run pytest in any folder within leapp-repository directory structure, it picks up the pytest configuration file leapp-repository/conftest.py which calls the leapp framework to load the leapp-repository.
Are you suggesting to make the conftest.py smarter and not call the leapp framework when you try run pytest x.py where the x.py does not include anything leapp framework-related?

[bocekm]

@examon, I've created RHELLEAPP-1869 to deal with this. On top of backlog ;)

[pemensik]

I am trying to test my own bind configuration parser. It is much faster to test basic library in separate test. It is also much faster to debug it. Then without modification, test it as leapp library in second step.

I would suggest to move framework initialization into separate module. Make for example import leapp.test, which would initialize complete environment. Not only it always configures leapp. Problem is it cannot handle exception in its configuration, even no single leapp module was imported. Or try to hook it into leapp module. If any submodule is imported, it is fine. But it should not block simple scripts, where such failure is not an error.

I think it should trigger error only on loading leapp namespaces provided by leapp-repository. Maybe it could define function for repo initialization, which would change some value in leapp.actor and/or leapp.libraries.actor module? It would be called for any importing such modules, but would be skipped for unrelated scripts.

[bocekm]

@pemensik, can I close the issue based on #367?

[bocekm]

Seems like done.

[pemensik]

No, actually that fix was just handbrake. It did not fix primary issue. It just provided a way to work around.

I have problem with import system of actors in project. It is hard to develop fragments of Actors on Fedora box, because no packages are provided. And unnecessary dependencies on repository itself. But I will open new issue when I am able to formulate better why I think current import path system is broken. For now, It is just difficult to use PYTHONPATH to have imports working. Why is there some virtual leapp.libraries.common, when such file is not directly provided?
More later

[pirat89]

Why is there some virtual leapp.libraries.common, when such file is not directly provided?

Not sure what do you mean by that. It's possible that I missed the point, so in case you find my point completely unrelated to the topic, just ignore it. But I believe this is better than write people they have to watch into the repository to find out what path they should use - instead of something you can refer simply and people can find it, doesn't matter name of repositories. Similar thing for actor. Imagine that every actor would need different import paths. Imagine you want the hierarchy structure of repositories. Why to use long nonsense imports? After time, I thing this is very elegant solution in regards to generic structure of leapp repositories.

But as I told, it's possible that I missed the point. Still, when you formulate properly your problem in a new issue, it will be easier to discuss it, fix it or find a way to improve the experience. But in case that imports are problematic, it's issue for leapp - not leapp-repository.