devbisme / skidl

SKiDL is a module that extends Python with the ability to design electronic circuits.
https://devbisme.github.io/skidl/
MIT License
1.04k stars 118 forks source link

Import paths extension #169

Closed mawildoer closed 1 year ago

mawildoer commented 1 year ago

If a complete path is provided and exists on one of the search path, take it.

This is useful for storing project dependencies in a projects top-level dir and programmatically adding this to the search path.

devbisme commented 1 year ago

Thanks for the modification! Can you give me a concrete example of what this modified function does that the existing function does not do? What new capability is this providing?

mawildoer commented 1 year ago

We've been working on dependency management within the KiCAD ecosystem a little.

Looking to how SW compilers deal with dependencies, we wanted to have the option to explicitly list the module you're interested in.

Analogously to Python, you can't just import foo.py. There might well be multiple colliding projects that contain a module foo.py, so you need to specify a path instead. In python that means <package>.<package>...<module>, for SKiDL this modification means you can do the same (with directories instead of packages) relative to some path on your search path.

Usefully it means that you can create "environments" of dependencies shared amongst projects, which in my specific case means pulling in project dependencies from a metadata file to a directory at your project's top-level, in similar fashion npm.

We're working on some tooling that'd use this functionality to easily mirror correctly versioned dependencies to the user's local machine on installation of the project, without pulling in entire repos in the form they regularly exist at the moment (jake's component library)

devbisme commented 1 year ago

Thanks for the further illumination! Based on what you said and from testing the code, it looks like your find_and_open_file function will accept relative file names like c/d/e/fn.txt and a search path like /a/b and will search for and open /a/b/c/d/e/fn.txt. Is that correct?

One difficulty I'm having is you made the PR against master, but the development branch has a modified find_and_open_file function that also handled URLs. So your version isn't just a drop-in. Therefore, I made a new branch called my_find_file that modifies the function to add the feature you need (I think). Please give it a try. If it works, then I'll merge my_find_file into development.

devbisme commented 1 year ago

We never came to a conclusion on this. I went ahead and merged my version into the development branch. You can re-open this if you find it doesn't meet your needs. Thanks for your contribution!