[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bindings
Subject:    Re: [Kde-bindings] Twine2 (PyKDE* code generation tool) Naming
From:       Scott Kitterman <kde () kitterman ! com>
Date:       2015-04-07 21:36:22
Message-ID: 5771041E-776B-4B26-90DF-A32269ED9DE7 () kitterman ! com
[Download RAW message or body]

On April 7, 2015 2:13:58 PM EDT, "Dennis Nienhüser" <earthwings@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@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@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@kde.org
> > https://mail.kde.org/mailman/listinfo/kde-bindings
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings@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
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings


[prev in list] [next in list] [prev in thread] [next in thread]