Build from repository

[rnewton]

Just for the sake of context: I'm building a bit of a wrapper project around this that will handle auto-configuration of projects. My workflow, in general, is to

1. Do a clean checkout of the repo I'm currently working on
2. Create a branch to hold my feature/bug
3. Initialize the project (we use ant)
4. Watch for the directory for changes and rsync to a remote server (sometimes)
5. Do some configuration (vhosts) on that same remote server (sometimes)
6. Finish my work and commit, push.
7. Wait for testers to be done and then delete everything.

While the majority of that doesn't fit in with the philosophy of desk and is really specific to my workflow, the bit about checking out from a repository might be. I'm envisioning something like

$ desk build github.com/owner/repo [desk-name]

Where you would previously configure where you want the projects to live (like configuring where you want the deskfiles to live).

This would create some stub deskfile (desk-name.sh) and do the git clone in your project directory.

The biggest things that I'd see with this are:

1. Tying desk to a specific scm (git) or host (github) OR trying to generalize and really bloating the code
2. Requiring an additional template file that would need to live somewhere and have a reference
3. Requiring users to configure and create a project directory

Maybe not ideal as laid out here, but potentially could be hammered into something useful :smile: I'd like to hear your thoughts on this, @jamesob.

[jamesob]

Yeah, I'm definitely interested in supporting something complementary at desk's layer. Thanks for the detailed write-up of your thoughts.

I've been drafting a behavior to facilitate easy sharing of project-specfic deskfiles that may dovetail with your flow. Imagine a convention where we had Deskfile (or deskfile.sh, either way) live at the root of a project's source tree. You check out the project, cd into it, then run desk import .. This would symlink the project Deskfile into your $DESK_DESKS_DIR.

Question there is: some (maybe most) deskfiles start off with a cd ~/project/dir... how do we handle that in an imported deskfile, where the path of the project's checkout is unknown?

One option would be to support some comment syntax for saying "this is a project deskfile; if it's symlinked, read the link and cd to the basedir of the source." Something like

# /tmp/checkout/spectac_proj/Deskfile
#
# Description: my spectacular project
# Name: specproj
# Root: .

alias whatever='baz'
...

So then when you desk . specproj, it reads the symlink and cds you into /tmp/checkout/spectac_proj. I'm not wild about having to specify the name, so maybe we could think of a clever way to infer that.

What do you make of the above? Would it be useful for your wrapper?

---

I think your instinct is right with regard to the caveats you list: at some point I'd like to be able to optionally recognize git (and other vcs) if it's easy, but I definitely don't want to take on any dependencies in doing so. It requires some more thought, but I think there's potential there.

[rnewton]

I like this approach better for the general use-case. It doesn't really match what I'd be able to do immediately as I'm the only one evaluating desk at my company at the moment and it might be a hard sell to place another file at source root (to live with grunt, npm, composer, bower, etc). However, I could easily get my wrapper script to 'inject' the deskfile into the project after checkout and then follow the same flow you describe after that point.

I can't think of a way to infer things like the project directory or the name of the project that aren't fraught with special cases or magic. In any case, I'm not opposed to optionally specifying the name and root directory, but we'd just have to be careful to not require too much configuration right off the bat.

[TristanBurnside]

I also think some sort of project specific setup would be really useful.

Why not just get desk to search for the deskfile in the current directory first, then if it doesn't exist look in $DESK_DESKS_DIR?

That would resolve the cd ~/project/dir... issue because you will already be there, just open the new shell at the current directory of the old one.

[flosell]

@TristanBurnside: +1

[jamesob]

Sounds good -- I'll throw together an implementation for that pretty soon.