Installing python __init__.py file from multiple KF5 frameworks

[Elvis Stansvik]

2016-06-08 8:58 GMT+02:00 Stephen Kelly <steveire at gmail.com>:
> Elvis Stansvik wrote:
>
>> 2016-06-06 11:42 GMT+02:00 Elvis Stansvik <elvstone at gmail.com>:
>>>> In data giovedì 19 maggio 2016 19:00:07 CEST, Stephen Kelly ha scritto:
>>>>
>>>>> have to be changed for the namespaced module stuff?
>>>>
>>>> Sorry, you were perfectly clear. It was me who didn't get the request.
>>>> ;)
>>>>
>>>>>  SOME_PYTHON_2_LOCATION/PyKF5/__init__.py
>>>>>  SOME_PYTHON_2_LOCATION/PyKF5/KWidgetsAddons.so
>>>>>  SOME_PYTHON_2_LOCATION/PyKF5/KItemModels.so
>>>>>  SOME_PYTHON_3_LOCATION/PyKF5/__init__.py
>>>>>  SOME_PYTHON_3_LOCATION/PyKF5/KWidgetsAddons.so
>>>>>  SOME_PYTHON_3_LOCATION/PyKF5/KItemModels.so
>>
>> So to conclude, I think from a user POV the above layout would be
>> best. No namespace packages involved here, the __init__.py would be
>> empty. It would be up to packagers how they want to handle the
>> conflicts (excluding the __init__ from all the packages and instead
>> having them all depend on a package that provides it, or maybe using
>> some mechanism they already have in place to handle cases like this).
>>
>> If someone else has a better idea for a solution that would allow
>> users to do from `KF5.<Framework> import <Symbol>` while at the same
>> time minimizing packaging hassles, please speak up since I'm by no
>> means an expert on the Python import mechanism and may have missed
>> something!
>
> Hi Elvis,
>
> Thanks for your contribution and analysis! I agree with you that
>
>  from KF5.<Framework> import <Symbol>
>
> should work. I have not yet tried the proposal from Luca, but if it doesn't
> allow that then that's also a reason it should not be used for me.
>
> I also prefer the above layout, partly because I can't find any project
> using the alternative layout that Luca proposed. I don't think we should be
> pioneers on this issue.
>
> I'm not yet sure the __init__.py should be empty though. If it contains the
> variables __all__ and __version__ then the following works:
>
>  import PyKF5
>
>  help(PyKF5) # Shows the correct version in the VERSION field
>
>  from PyKF5 import * # Imports all of the modules
>
>
> There may be other content that make sense in the __init__.py file. As far
> as I can tell, packagers should be able to split this out and handle it

BTW, could we not provide this single-__init__.py-package as an
upstream thing (frameworks-python-common?), something which Tier 1
frameworks that have Python bindings will depend on?

I know this would make that package "Tier 0", kind of like ECM, which
is bad. But I think having these packages install conflicting files
(even if identical) from the get-go is possibly worse.

Elvis

> without problems. The layout proposed by Luca is the 'ultra modern' way that
> no one seems to be doing yet.
>
> Thanks,
>
> Steve.
> _______________________________________________
> Distributions mailing list
> Distributions at kde.org
> https://mail.kde.org/mailman/listinfo/distributions