Relative import tool

[MadisonAster]

Would anyone mind reviewing my recent project? I've written this in a procedural style, because my goals for this project were very simple and clear.

Readme:
https://github.com/MadisonAster/FooFinder

Main code:
https://github.com/MadisonAster/FooFinde..._init__.py

Test code:
https://github.com/MadisonAster/FooFinde...er/test.py

The goal of this tool is mostly to make it easy to create modular structures for new and experimental projects, which can later be replaced with an explicit structure before shipping. I haven't had much luck finding people to gather opinions from, so I thought I would try here.

[Atekka]

This is an interesting concept, though from first glance it seems like it might end up further complicating whichever projects you use it on. While it's nice to have more confidence that your imports will be imported, I can't help but imagine the potential complication of later trying to re-organize your project structure to then have explicit imports when, in most cases, you should just have organized it properly to begin with.

That being said I can also imagine cases where you may be working on scratch files and want to quickly gather some imports from the main project just to get a proof of concept, without having to re-arrange things. In that situation this could be pretty handy. So in my opinion this could be a useful tool for experimenting with things before locking in a concrete structure, but should of course be used as a tool for experimentation and not so much for lazy beginners who just don't feel like getting to know the proper structure of a python package. As long as that's clear to people, and it's used for it's intended purpose, then it's got it's benefits.

I think it's pretty neat that you've accomplished such a lenient way to gather that Foo you're looking for. I haven't gone into depth with the source but it's clearly functional so good job figuring it all out. Like I said my only concern is towards the potential it has to complicate a project if it's not used correctly, but I'm sure whoever uses it will be aware of that pitfall and will use it the right way. So hopefully I haven't entirely misunderstood, and that this is useful commentary on your work. Overall you've accomplished the finding of Foo and with that being your goal, congratulations on your success. I'm interested to hear what other peoples thoughts are too. Thanks for sharing.

[MadisonAster]

Thanks for taking the time to review ^-^!

I agree that someone could definitely shoot themselves in the foot with this thing, and probably isn't a great tool to give to a beginner. Because of the work that I put into limiting the recursion scope, and the way you have to name the thing you're looking for, I think it would be safe in 99.99% of cases. Even with that certainty though I don't believe it would be appropriate to depend on this in a redistributed package.

I have found 2 production use cases that I think it's essential for though. The first is ipython notebooks, because notebooks are designed to be a container for things like stock ideas. The natural tendency is to want to organize them with a meandering nested folder structure because that's kinda just how ideas work. But notebooks often need to import a central module from the repo they live in. Here is an example where the author expects you to copy the notebook files out of the nb folder, and up one directory before you can begin using them:

https://github.com/rsvp/fecon235

I've corrected this so that the notebooks can run in place without requiring the user to do any reorganizing, by adding:

from FooFinder import fecon235

Here's the corrected fork:
https://github.com/MadisonAster/fecon235

The 2nd use case that I've run into professionally, has been in building software pipelines. Often a module depends on some central module that imports it, but that module also needs to sometimes be run as __main__ by some other outside program. "from FooFinder import CentralModule" cures this.


My "code garden" project also depends on it. It's a permanently experimental project that I've been tinkering with to provide a general connectivity framework between various languages and tools. I'm trying to make the modules 100% modular, for recyclability purposes. Tests live with the code, and the modules depend on each other relatively. Example:

https://github.com/MadisonAster/KungFu/b...Cluster.py

https://github.com/MadisonAster/KungFu/b...Cluster.py

[Gribouillis]

Will FooFinder work with submodules of a zipped python package?

[MadisonAster]

Hi Gribouillis, fantastic idea! I just wrote a test for this, and as I expected FooFinder does not currently work with this. I'll work on including this functionality. Thank you so much for the feedback!

[MadisonAster]

I've added support now for zip files in v3.0.6

Here's how the syntax works:

ParentFolder/
    ZippedFile.zip/
        ZippedPackage/                      <- and you want to import this zipped package
            __init__.py
        ZippedModule.py                     <- or this zipped module
    SubFolder1/
        SubFolder2/
            CurrentModule.py         <- you are here

from FooFinder.ZippedFile import ZippedPackage
from FooFinder.ZippedFile import ZippedModule

This uses zipimport.zipimporter.load_module to do the loading of ZippedModule or ZippedPackage, so it's limited to just what zipimporter can see. Searching the contents of the zip folder recursively would make it more complicated, and I couldn't think of a good use case for it.