[Kde-bindings] Twine2 (PyKDE* code generation tool) Naming

[Scott Kitterman]

On April 7, 2015 2:13:58 PM EDT, "Dennis Nienhüser" <earthwings at gentoo.org> wrote:
>Hi Scott,
>
>sounds fine to me. For configuring paths I'd prefer sane defaults with 
>command line overrides to a config file. For 2. ksipbindings sounds a 
>bit strange if it contains non-binding specific code, can you elaborate
>
>a bit what would go inside?
>
>Regards,
>Dennis
>
>Am 06.04.2015 20:00, schrieb Shaheed Haque:
>> The refactor sounds good.
>> 
>> As for a configuration file, you might care to look at the patch I
>> posted in the other thread for an alternative approach; its not quite
>> right because (a) IIRC the norm for KDE builds is for all the repos
>to
>> be at the same level and (b) the output ("build") directory is
>> conventionally taken as the current directory and (c) I'm a bit stuck
>> becuase I just cannot seem to make *anything* build.
>> 
>> If that does not suit, then I'd argue for overrides by passing args
>> into kf5.py. That could be run from cmake to end up with something
>> that builds like any other KDE package.
>> 
>> On 6 April 2015 at 17:45, Scott Kitterman <kde at kitterman.com> wrote:
>> 
>>> I've started looking at refactoring twine2 into a common module that
>>> can be
>>> used in (and shipped with) kf5 and the legacy KDE SC bindings. It
>>> seems
>>> reasonably tractable.
>>> 
>>> I need a Python module name for the common module. I don't think
>>> twine2 is a
>>> good name since twine is already in use for a popular tool on pypi:
>>> 
>>> https://pypi.python.org/pypi/twine/1.5.0 [1]
>>> 
>>> My intent, unless someone objects is to do the following:
>>> 
>>> 1. Move all the current hard coded file locations to a
>>> configuration file to
>>> make it easier for everyone to use twine2 without having to edit
>>> source.
>>> 
>>> 2. Move the non-binding specific code into a module with TBD name.
>>> It doesn't
>>> need to be pretty, just distinct, so I'm thinking perhaps
>>> ksipbindings, but
>>> I'd love better suggestions.
>>> 
>>> 3. Refactor kf5.py, kdelibs.py, and kdeedu.py to use the module.
>>> 
>>> 4. Add more command line options to make things generally more
>>> configurable.
>>> 
>>> Does that sound OK? Is anyone else working on something that this
>>> would
>>> conflict with?
>>> 
>>> Scott K
>>> _______________________________________________
>>> Kde-bindings mailing list
>>> Kde-bindings at kde.org
>>> https://mail.kde.org/mailman/listinfo/kde-bindings [2]
>> 
>> 
>> 
>> Links:
>> ------
>> [1] https://pypi.python.org/pypi/twine/1.5.0
>> [2] https://mail.kde.org/mailman/listinfo/kde-bindings
>> 
>> _______________________________________________
>> Kde-bindings mailing list
>> Kde-bindings at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-bindings
>_______________________________________________
>Kde-bindings mailing list
>Kde-bindings at kde.org
>https://mail.kde.org/mailman/listinfo/kde-bindings

Basically everything but kf5.py, kdelibs.py,  and kdeedu.py would go in it.

Maybe kbindinggenerator?

I don't care much what we pick. I mostly want it to be distinct enough to not cause confusion and to not spend a lot of time bike shedding the name. 

Scott K