[HN Gopher] Kraken Technologies: How we organise our large Pytho...
       ___________________________________________________________________
        
       Kraken Technologies: How we organise our large Python monolith
        
       Author : rbanffy
       Score  : 29 points
       Date   : 2023-07-18 19:56 UTC (3 hours ago)
        
 (HTM) web link (blog.europython.eu)
 (TXT) w3m dump (blog.europython.eu)
        
       | photonthug wrote:
       | Never heard of https://import-linter.readthedocs.io/ before. Not
       | sure if I like this type of solution, but it's interesting, and
       | certainly the problem is real.
        
         | bitdivision wrote:
         | The author, David Seddon, is also the author of the package
         | [0]. So I'm guessing Kraken was an initial user.
         | 
         | 0: https://import-linter.readthedocs.io/en/stable/authors.html
        
       | CraigJPerry wrote:
       | This is java circa 2009 flavoured, this model was a popular
       | approach in the java community around that timeframe. Was
       | enforcer the name of the maven plugin? I can't remember now, but
       | it became fairly popular.
       | 
       | I wonder if this might be susceptible to the same issues that we
       | had in java, specifically it doesn't prevent accidental
       | duplication, it makes refactoring harder/slower and it's
       | problematic for the team when it unexpectedly doesn't catch a
       | misuse - and this happens because the rules enforcement can only
       | happen effectively if the rules themselves are perfect and
       | complete and that gets harder to guarantee with scale and speed
       | of iteration.
       | 
       | For my money today, there's another model "polylith" which is
       | similar in some ways and as easy to understand but maybe simpler
       | to evolve/change your mind over time.
        
         | photonthug wrote:
         | > this happens because the rules enforcement can only happen
         | effectively if the rules themselves are perfect and complete
         | and that gets harder to guarantee with scale and speed of
         | iteration.
         | 
         | IMHO, project-level assertions about initialization-order feels
         | a little bit dirty, but potentially practical as long as
         | there's only a few rules. Surely even a bazillion line monolith
         | can still often be thought of in terms of a few layers. But by
         | the time you get to lots of rules it's getting hard to stomach
         | the code-smell and keep justifying it as practical. At that
         | point I'd want something dynamic and backed by a real solver..
         | not just a layer of static-analysis.
         | 
         | The deal framework for DBC doesn't quite do this afaik but is
         | starting to expose some stuff along these lines, and at least
         | can assert imports are "pure".
         | https://deal.readthedocs.io/details/module_load.html
        
       ___________________________________________________________________
       (page generated 2023-07-18 23:00 UTC)