fabric is building openbts metapackage instead of osmocom when running 'fab osmocom dev package'

[kheimerl]

I've tracked it down to the following:

if package_common == 'yes':
    (f, modpath, desc) = imp.find_module('fabfile', [COMMON_DIR])
    if f is not None:
        common = imp.load_module('common_fabfile', f, modpath, desc)
        f.close()
        execute(common.package_common_lib)

The load_module call is resetting env.gsmenv to the default: 'openbts'

[9muir]

I stumbled across this too a couple of weeks ago but got distracted. I can't remember if I had a fix, let me dig through my code

[kheimerl]

i have an ugly one I'm going to push soon.

[9muir]

I see, it's probably the circular load_module calls, and the fact that client/fabfile.py resets env.gsmenvunconditionally. The loading of client/fabfile.py from common should probably be conditional upon it not already having been loaded.

[kheimerl]

It's a new fabfile being loaded though, so I think it has to happen.

My solution is to just copy the env before the command and reset it after.

On Wed, Jun 14, 2017 at 12:29 PM, Steve Muir [email protected] wrote:

I see, it's probably the circular load_module calls, and the fact that client/fabfile.py resets env.gsmenvunconditionally. The loading of client/fabfile.py from common should probably be conditional upon it not already having been loaded.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/facebookincubator/CommunityCellularManager/issues/58#issuecomment-308534144, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_rn0Y3FqD1O20NJuSGe5CuJcilAmsmks5sEDSjgaJpZM4N6OZM .