mvanveen / al Goto Github PK

As a user, I should be able to namespace my aliases into different profiles.

Options:

1. .alias.profile
2. .alias/profiles
3. within .alias/profiles: personal work lab etc.

Regarding 2., this follows in the vim tradition, no? Like there's a .vim dir in your home directory, and within are a bunch of configs and plugins. I like that fine :) Does it suffer in portability though?

• Must detect shell with:

import os
os.environ.get('SHELL')

TODO: Confirm that alias format is POSIX.

• If not, determine which shells to support

Allow alias profiles to be loaded and unloaded depending on context.

• SO Thread about aliases
• Should allow multiple .alias files

As a user, I should be able to use different profiles in different contexts.

• When I go to ~/projects/work, my work bindings are available
• When I go to ~/projects/mycoolproject, my project-specific bindings are available

Killer App

As a user, I can type make into the console and it will just "do the right thing."

Q1: How does a user set a context-specific alias?
Q2: Should anything other than your current file path be included in the context?

Introduction

Abstract

Tags are really nice if we want to hit contextual use cases. For example, a ruby dev on osx might have
different aliases than another ruby dev on linux. Tags would be helpful for capturing this info in a way
that profiles could not support.

Use Cases

• User can add a tag to a new or existing existing alias

$ al <alias name> <alias value> --tag <tagname> 

• User can add multiple tags to an alias (existing or new)

$ al --tag <tagname1>, <tagname2>, <tagname3> <alias name>

Design

Support for tagging means our backend is probably something a little bit more flexible than just aliases
name-spaced to a profile. It likely means that al has its own backend format.

Keeping things simple as plain text seems like the easiest way to go. And it is in line with the unix
philosophy, which is a goal of this project (side note: Keeping in line with unix/plain-text is probably
crucial for bolstering support).

Aliases

Let's store aliases flat-file in their true POSIX form. This keeps it simple and flexible with other systems.

We can store them in a giant file in .al/aliases, one per line.

alias gc="git commit"
alias gc="git checkout"

Tags

Keep tags in YAML. Each tag contains a list of key, value pairs. Each key is an alias and each value is
a list of possible commands.

There's a special reserved tag called commands which saves the entire tree of aliases.

commands:
  - gc: ['git commit', ' git checkout']

HEAD:
  - gc: ['git commit']

python:
  - gc: ['git checkout']

Overlap

Some alias names will overlap. We need a way to deal with this if we're just keeping a list of aliases.
Storing overlapping aliases isn't such a problem if our aliases file keeps them separate by newline.

The real problem emerges when you want overlapping aliaes in-play at the shell. Simply put, you can
only have one value per alias set at the shell.

We can create a special reserved tag (HEAD) which keeps track of which commands are in-play. The
special rule governing HEAD is that a key can only have one value.

Profiles

A profile is a configuration of tags in a YAML file, combined with the sourced aliases.

Users will likely want to use different profiles in different contexts.

The best idea I have so far is to use git for what it's good for and store these configurations as separate
branches.

$ al --profile <profile_name> <alias name> <alias valie>