I doubt the benefit of these specialized edit commands. Is the Spack directory tree too hard to navigate around?

@citibeth: I use these all the time. Why the opposition?

I doubt the benefit of these specialized edit commands. Is the Spack directory tree too hard to navigate around?

The same could be said about spack edit <package>, although that directory tree is slightly deeper 😆

I use them all the time too. Super useful.

Why the opposition?

I will decline to hijack this thread; see #2867 for the full rant.

The same could be said about spack edit

There's a difference of degree here. spack edit <package> is (marginally) for Spack users who wish to add packages to Spack. spack edit -b is useful only to Spack developers --- an increasingly tiny portion of the Spack community. If neither command existed, we would still get along just fine.

@citibeth:

spack edit -b is useful only to Spack developers

Yes. Developers make the project happen. I want to keep them happy.

Do we want to consider adding options for other subdirectories of lib/spack/spack?

Are you serious, or asking in jest? This is exactly the absurd state we would do well to avoid.

If we want a convenience command to edit stuff, how about something general. Something like: spack edit compiler gcc, spack edit platform linux, spack edit buildsystem cmake, etc.

Or even better.... if we can manage to flatten the directory hierachy, we just do: spack edit <directory> <file>, which throws up the editor on ..../<directory>/<file>.py. Why did we invent the namespace that we use in the filesystem, if we then wish to throw it out and replace it with a completely different namespace inside the spack edit command?

Another thing to consider is... how hard would the spack edit -b command be to implement using a single-line Bash alias? Can't we expect developers to create edit-command aliases if and when they find it convenient, without having to add new Spack commands to do the same thing?

Do we want to consider adding options for other subdirectories of lib/spack/spack? We could easily add -p for platforms and -o for operating_systems.

I would say whatever you frequently edit and want a shortcut for. I was actually thinking about adding support for spack edit --docs packaging_guide someday.

I would say whatever you frequently edit and want a shortcut for.

As is commonly the case, the I use are remote, and shell/X11 connections cause noticeable usability problems with editors. I solve this problem with Emacs TRAMP: the editor runs on my local machine, and I'm editing files on the remote machine where Spack runs. I just don't use spack edit because it just doesn't work in such environments.

In #1537 I suggested a symbolic link be added to provide a shortcut into the Spack directory tree. This was rejected; but maybe we can reconsider? All this spack edit magic does nothing for me, and I am left forever navigating through directory hierarchies with my Emacs, command shell, etc. A carefully designed set of shortcut symbolic links, plus a simple spack edit command, would be more useful, more transparent and easier to maintain, than an ever-expanding suite of spack edit sub-commands.

For example... suppose we create a directory spack/shortcuts. In it, we add symbolic links to other directories in the Spack tree. For example... doc, buildsystem, package, platform, compiler, etc.

Now, the command spack edit <shortcut-dir> <name> could just edit the file spack/shortcuts/<shortcut-dir>/<name>.py. (Except for packages, which are just slightly a special case).

In addition, to improving spack edit, these symlinks would also be useful for:

1. Emacs / IDE users, who launch their editor once and don't use a command-line edit command. (Yes I know such a command exists for Emacs; but it never quite works for me.)

2. People editing their Spack files remotely (I use Emacs TRAMP; which makes the spack edit command pretty useless).

3. People who want to cd, grep or find in one of these directories.

Yes. Developers make the project happen. I want to keep them happy.

Rejecting #1537 did nothing to make this developer happy, and beefing up spack edit unfortunately is not a substitute.

@citibeth: have you tried spack cd -p?

Sorry: should be spack cd -P

It requires Spack's shell integration, which I don't use. More useful would be a command that just prints out the directory. Then I could type:

cd `spack dir ...`

But seriously... what's wrong with #1537? Yes, I can re-read what you wrote there. But is it really so bad compared to the other roads we're considering going down? Moreover, spack dir or spack cd -p won't do anything for me with my editor.

The options for spack edit really aren't a problem for the average user. They aren't in the documentation, and even if they were, no one is forced to use them. spack edit, by default, opens a package file. If you give it other options, it will open other files. What you're proposing would be to convert:

$ spack edit hdf5
$ spack edit -c create
$ spack edit -b autotools

to:

$ spack edit package hdf5
$ spack edit command create
$ spack edit build_systems autotools

Why would this be beneficial? It's more typing, and the user has to look up whether it's build_systems or build_system. Anyway, neither would help you due to the fact that you use emacs. Vim ftw!

@adamjstewart: I think @citibeth just wants clearer help text and groupings in the argument help, not subparsers.

It requires Spack's shell integration, which I don't use. More useful would be a command that just prints out the directory. Then I could type:

cd `spack dir ...`

Did you try:

$ cd $(spack location -P)

Which is what spack cd actually does?

Out of curiosity, why not use the shell integration?

Did you try:

$ cd $(spack location -P)

Which is what spack cd actually does?

No, because it's just not very useful. I need to point my editor (on my laptop) to the correct location, not my bash shell (on the supercomputer).

Anyway, this is stuff that I could set up very easily in my .bashrc:

export SPACK_HOME=....
export SPKG=$SPACK_HOME/..../packages

Or if I liked what spack cd -P does, I could do, for example:

alias scdp='cd $SPKG'

All of this is an order of magnitude simpler than creating a new Spack command. But none of it actually makes my life much easier because my EDITOR, not bash shell, needs to find its way around the Spack tree structure.

Out of curiosity, why not use the shell integration?

I'm not sure why it's not working right now; probably has something to do with my efforts to get a good Spack environment of the packages I needed to install, and changes I made to my .bashrc. I didn't miss it (or notice it wasn't working) until I tried spack cd.

What you're proposing would be to convert:

$ spack edit hdf5
$ spack edit -c create
$ spack edit -b autotools

to:

$ spack edit package hdf5
$ spack edit command create
$ spack edit build_systems autotools

Why would this be beneficial?

Because it increases the consistency and rationality of the system. Small systems can afford to have crazy idiosyncratic conventions. The larger a system grows, and the more users are involved, simplicity and clarity increasingly becomes more important than saving keystrokes.

It's more typing, and the user has to look up whether it's build_systems or build_system.

That's what bash aliases are for. If you use spack edit build_system a lot, then you can do:

alias sebs='spack edit build_system'

Alternatively, if one-letter names for these features are good, we could always create one-letter symlinks as shortcuts, instead of the full-word symlinks I suggested. Then you could do spack edit b cmake, for example. Or call the symlink -b if you like dashes. But I think that if this were proposed, people would rightly call it out for being cryptic.

Anyway, neither would help you due to the fact that you use emacs. Vim ftw!

That's not the point. The real issue is these don't help me because I edit files remotely --- a feature that many Spack users likely take advantage of, or would take advantage of if they knew how to do it in an editor they like. The editor is running on my laptop, while Spack runs on a remote computer.

This feature is also available in Vim: vim.wikia.com/wiki/Editing_remote_files_via_scp_in_vim But once you try to use it, spack edit suddenly becomes useless. As with Emacs TRAMP, there are many more flexible approaches we COULD use that would support remote editing. But currently we don't.