storborg/dram

Keeping your package manager packaged.

dram's Issues

Add dram-cmake and dram-configure commands

Add new commands which alias/replace e.g. cmake $DRAM_CMAKE_FLAGS. That way, the original commands (cmake and ./configure) can be caught and the shell can warn and prompt the user to continue. This should reduce the risk of accidentally "escaping" the dram environment.

Make environment creators more extensible / scriptable

Not sure of good ways to do this, but it should be easy to add a new creator.

Add specific command help

It'd be cool if we had help for the specific commands, i.e. dram help create would show help for the create command.

The plain-with-python setup should add a prefix symlink to virtualenv

Specifically it should make e.g. /dram/blah/lib/python2.7/site-packages point to /dram/blah/pyenv/lib/python2.7/site-packages. This is because a bunch of packages will install their python modules into a path that is directly based on the PREFIX, rather than based on the actual real python environment.

When creating new dram, ensure that the desired dram does not already exist

Dram allows you to create a repo with the name "-t"

Dram names should probably be restricted to ^[a-z0-9][a-z0-9-]*$

Creating new dram should fail if there's an existing dram active

"dram help" doesn't list the cdsource command

dram configure directory detection is broken

dram configure warns that we aren't inside the active dram when we are.

Is there any way to 'unuse' a dram?

I'm afraid it's causing problems with resolving paths or something. I'd at least like to disable it and see if it fixes anything. Should I just create a separate empty dram and switch to it?

Use either DYLD_LIBRARY_PATH or LD_LIBRARY_PATH

...but not both. Select based on uname output.

Add real help/usage strings

Add a shell installer

Add an installation tool that sets up the dram root dir and sources the dram.sh script in the shell. This could be implemented as either one of:

• A setuptools install cmd class which performs the appropriate operations.
• An additional command-line tool, e.g. dram-install, which performs the appropriate operations. This could also interactively prompt the user for settings and configure them appropriately.

Improve dram installer

• Use ~/.profile instead of ~/.bashrc on OS X
• Eliminate all dependencies to improve robustness
• Elevate privileges when creating dram root if necessary
• Default to using a dram root inside of home dir

dram help doesn't list all commands

dram configure and dram cmake are missing

Check return status of commands that can fail

In dram list, show currently active dram

Add promote/demote commands

dram promote foo - If foo is an executable that is inside the currently enabled dram, set a symlink from /usr/local/bin/foo to foo. Note that this will only really work for statically linked executables. Check to make sure that foo isn't already present in a different global path. If so, refuse to do anything, unless -f is passed.

dram demote foo - If foo is a symlink inside /usr/local/bin/ that points to an executable inside a dram, remove it. If not, refuse to do anything.

Figure out a story for managing permissions in a multi-user dram setup

If a single machine is shared by multiple users, and shares one DRAM_ROOT, dram could be more intelligent about managing permissions: perhaps with judicious use of g+s and a dram group, or something similar.

If possible, dram should wrap lldb on os x 10.11 to forward the dram environment vars

Due to SIP, lldb on os x 10.11 doesn't work in a dram. This can be fixed, see this stackoverflow post. dram should provide an alias that does this, if possible.

dram_confirm_unsafe grabs the wrong part of the command to complain about

e.g.

(pyenv) skysafe@fessenden:/dram/uhd-master/source/uhd/host/build$ cmake $DRAM_CMAKE_FLAGS -DLIBUSB_INCLUDE_DIRS=$DRAM_ROOT/$DRAM/include/libusb-1.0 -Wno-dev ..
Dram is active, are you sure you want to execute -DCMAKE_INSTALL_PREFIX=/dram/uhd-master? [y/N] 

Should show are you sure you want to execute cmake?

Add an info comment to each activate script when created

When creating a new dram, it would be helpful if the activate script included a bit of info about it. For example, dram type, username that created it, creation time, hostname it was created on.

dram cmake and dram configure should pass through arguments

There should be a way to pass through arguments when using dram cmake and dram configure

Immediately activate dram after creating

It'd be nice if dram supported bash autocompletion

Add a plain-with-python creator

Use more strict bash idioms

See http://redsymbol.net/articles/unofficial-bash-strict-mode/