Is it really a good idea for the imports list to be separate? about peru HOT 12 CLOSED

It might be a good idea to lampshade this in the "Getting Started" section of the readme, after the hello world example.

from peru.

Imports are not necessarily one-module-one-path.

To put multiple modules into a single import directory, what do you think about using imports-group? It seems like a potentially viable syntax for preserving Peru's existing architecture while opening up this useful bit of functionality. If imports and import-groups have a common namespace, then modules can use either of them. Perhaps we could still find something better; it struck me as a good starting point.

from peru.

I'm not sure I totally understand your suggestion. When you say "multiple modules into a single import directory," are you talking about arranging things so that multiple modules' files end up mixed together? That's possible now, with imports like this:

imports:
  module_a: all/modules/here
  module_b: all/modules/here
  module_c: all/modules/here

The files at the roots of those three modules will be mixed into the here directory; they will not have their own subdirs. Directories in those modules that have the same path will also get mixed. (Conflicting files cause an error when you're doing this.)

Or were you thinking of a more convenient syntax for doing imports like that? I'm particularly open to ideas that might simplify the beginner examples, but I want to be cautious in general of inventing More Than One Way To Do Things.

from peru.

Mixing looks interesting and potentially useful.

For this case, I'm interested in a convenient way to keep modules separately, while in the same parent dir. For example, by simplifying this code block:

imports:
  module_a: all/modules/module_a
  module_b: all/modules/module_b
  module_c: all/modules/module_c

to:

import-groups:
  module: all/modules

from peru.

I've imagined a similar idea before, maybe some kind of global config like this:

everything_goes_here: my/modules/dir/

git module foo:
  ...

That would save typing in the simple case where just want to fetch a bunch of different modules all to the same place. The big problem in my mind is that there doesn't seem to be a good way of having a feature like this interact with regular imports. Here are the options I can think of:

• imports are not allowed with the magical default paths. That would mean that as soon as your project gets more complicated, you can't use this feature anymore, so the feature wouldn't be very valuable. It would also mean that simple projects and slightly-more-complicated projects work very differently, which could be confusing.
• Using imports is in addition to the magical paths. I don't think anyone would put up with duplicated folders in their sync dir. This would end up working like above, with projects going all magic or nothing.
• Modules that show up in imports are automatically excluded from the magic. This might be the best option for saving keystrokes, but it makes things more confusing. Now the new field means "every module goes here unless it appears in this other place." And now imports means "here's everything you're going to get in your sync dir, unless you have this other setting turned on".

The problem at the end of the day is that we don't want to have two ways of defining imports that hate each other. We'd really prefer one feature that works well for both cases.

I could imagine something like allowing * globs on the left side of imports, so you could do something like "everything goes here" or "everything starting with js- goes here". An issue with that is now there's a difference between globbed imports (which have to tack on an implicit subdir name) and unglobbed imports (which are put literally where you said). And also I'm not excited about throwing imports: {'*': ./} at the top of hello-world.

So yeah, apologies for the wall of text, but I haven't been able to come up with a solution that helps with this problem without making things more complicated than they need to be.

from peru.

I don't know why I didn't think of this before, but if we wanted import to be a field within a module instead of a separate thing, we could allow it to take a list of values. We'd also need a way to express named rules. But it probably does come down to the question of whether we like to see all the imports at the top, or whether we want small files to be simpler / edits to be more localized.

from peru.

And maybe this is crazy, but if imports were listed in modules, you could actually specify which modules you want to sync...

from peru.

If we did this, we could name the field at.

from peru.

One option for a rules syntax would be:

git module foo:
  at:
    - path/without/rules
    - path: with/rules
      rules: [one, two]
  url: ...

from peru.

@olson-sean-k suggests:

git module foo:
  at:
    - put/foo/here : rule1|rule2
    - also/put/foo/here

from peru.

Some more thoughts about this today, this time on the negative side: A module definition describes a tree of files. The import path is not a property of that tree, it's a property of the larger project. One way this could get confusing is if you recursively import a module defined somewhere else. If the import path is given inside that remote module definition, does that mean it should apply to your project too? (It won't.)

Also for what it's worth, if we wanted to allow you to sync specific modules from the command line, there's nothing stopping us from doing that now. The interface would be exactly the same. Orthogonal feature.

from peru.

Another week of thinking about this has not made me like it more. Closing for now.

It occurs to me that we might someday want a feature that lets you group imports somehow. For example, if you fetch 100 vim plugins into vim/plugins and 100 zsh plugins into zsh/plugins, it would be nice to have a toplevel structure like

imports:
  all_the_vim_stuff: vim/plugins
  all_the_zsh_stuff: zsh/plugins

The definitions of all_the_vim_stuff and all_the_zsh_stuff could be defined and named somewhere else. They'd have less repetition of the path components, and it would be less likely that a one-off import (say, a random dircolors file) would get lost in all the noise. You could even have recursive imports where a remote repo defines these "named import trees" for you. Food for thought.

from peru.