Is there no simple way to import all files from a directory recursively?
e.g. import "../templates/*.nimf"
It gets on my nerves to specify each path, and to look at the growing result.
I saw this[1] already, but it's very old and the proposed solutions are not what i mean by simple.
Thanks
Maybe something like
import std/[os, strutils, macros]
macro importAll(folder, ext: static string) =
result = newStmtList()
for file in walkDir(folder, checkDir=true):
if file.path.endsWith(ext):
result.add nnkImportStmt.newTree(
newIdentNode(file.path[0 ..< ^ext.len])
)
importAll("../templates", ".nimf")
I haven't learned about macros yet, but that's not too bad. thanks.
I was wondering if nim's import had a built in way to do it that i just hadn't seen yet. Importing every file manually is not that bad for many projects, but writing a web app (cms in my case) is a little different. I've got paragraphs with many ../../ going on here! :)
That's not that helpful as language limitations shouldn't influence how you structure / split your code.
Thanks geotre for the macro to generate the import statements! It does make me wonder though if the same could've maybe been achieved via template, hmmm...
Language limitations are always a thing and they always influence how you can program.
And an "import whole directory" feature is not common in other languages either anyway, it's not a particularly special limitation.
And an "import whole directory" feature is not common in other languages either anyway, it's not a particularly special limitation.
It would just be a nice to have improvement for nim. Also, antiquated languages and their lack of care about DX, is one reason why i chose to invest in Nim. I don't know if it's hard to implement or would cause problems, but if not, i think people would like it. I can create an FR in the issue tracker if it would be entertained.
but i was also wondering why we have to import our own project's files at all to begin with.
explicit > implicit
especially for maintenance and refactoring.
Why not have the concept of local imports and remote imports ... dir(s) could be defined for local imports similar to my original question
The capability is there now - just adopt a convention of using a relative path for local imports. That is what I've adopted in the code I'm working on, so that I can visually differentiate between local and remote imports. It also has the side benefit of showing where in the directory structure a local import comes from.
For example:
import xyz # Remote import - package xyz
import ./abc # Local import - abc.nim in the same directory
import ../def # Local import - def.nim in the parent directory
import ../../dir2/ghi # Local import - ghi.nim in directory dir2 which is 2 levels up
import ./dir1/ [jkl, mno, pqr ] # Local import - jkl.nim, mno.nim, pqr.nim in subdirectory dir1
# ... and so on
IMO it would be useful if this convention were used generally - that way, when browsing a package's code, one could tell immediately whether an import comes from elsewhere in the same package or from one of the package's dependencies.
Importing the whole directories of code is usually a rare case
This is true and most project files don't have huge import blocks. I didn't really notice that i only have one file that has so many imports, so it's possible i could refactor, though i doubt that will make those imports go away, as opposed to just splitting them up. :)