Turbogears2 migration: tests: "cannot import name meta"

[Thomas De Schampheleire]

On Sun, Sep 25, 2016 at 4:10 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
> On 09/25/2016 04:04 PM, Thomas De Schampheleire wrote:
>
> On Sep 25, 2016 15:42, "Mads Kiilerich" <mads at kiilerich.com> wrote:
>>
>> On 09/25/2016 03:32 PM, Thomas De Schampheleire wrote:
>>>
>>> A question that also needs to be answered is: what belongs in
>>> kallithea/lib/helpers.py and what in kallithea/lib/utils.py and what in
>>> kallithea/lib/utils2.py. Where is the split?
>>
>>
>>
>> Yes, it is a mess. I guess that is where experiments must show what is
>> feasible improvements.
>>
>> I would say that helpers is what is available in templates as 'h' and
>> could/should thus be quite high level and might depend on Pylons and the
>> database.
>
> So actually, anything in helpers that is _not_ directly used from a template
> should be moved elsewhere (utils, or maybe helpers2? ;-)  )
>
>
> I guess that could make sense. Unless we consider helpers the very high
> level library that can be used from anywhere.
>
>> (It should thus perhaps not be in lib but in model?)
>
> I think the web framework, like tg2 does, may expect helpers to be in lib.
> We can tell it about another location, but I don't know if that's worth it.
>
>
> Hmm. That suggests that my idea of lib as low level and model as more high
> level doesn't work. That model perhaps should be considered an internal part
> of lib ... or something like that.

In a traditional MVC model-view-controller split, 'model' is one of
the three pillars. In that view, I think it shouldn't be 'stuffed
away' in lib.

I don't know if you should try to put model and lib on the same scale.
I think they are in some way orthogonal, especially things like
lib.{helpers,utils}. For me, the core of 'model' is the definition of
the data model, thus the database tables, and perhaps very related
set-up code.

'lib' is currently (but maybe logically) a 'trashbin', a collection of
code that does not really fit elsewhere, but can be considered
'libraries', i.e. each being standalone and doing some job that helps
someone else. 'utils'/'helpers' is even more a trashbin collection
that did not even fit in logically named files.

>
>>
>> It seems like utils2 generally is quite low level and almost doesn't
>> depend on model. It could thus seem like a/the "real" lib utils.
>>
>> utils depend much more on model, and parts of it should thus perhaps move
>> to a more high level model utils ... but there are probably also "good"
>> parts of it that can stay in lib.
>>
>
> It may perhaps be easier to step away from monolithic files and use topic
> files like foo_utils and such.
>
>
> Agreed, that would make it less of a mess. Also, some of the utility
> functions might be quite high level and doesn't have a natural topic. Except
> that then that could be the topic ... ;-)
>

misc.py ;-)

/Thomas