Include git in requirements

[aidanconnolly]

For those installing tarbell on linux, it is possible they don't have git installed. Then, when they go to install a blueprint, the command breaks in this block.

        try:
            puts("\nInstalling {0}".format(colored.cyan(template_url)))
            puts("\n- Cloning repo")
            git = sh.git.bake(_cwd=tempdir, _tty_in=True, _tty_out=False, _err_to_out=True)
            puts(git.clone(template_url, '.'))

            _install_requirements(tempdir)

            filename, pathname, description = imp.find_module('blueprint', [tempdir])
            blueprint = imp.load_module('blueprint', filename, pathname, description)
            puts("\n- Found _blueprint/blueprint.py")
            name = blueprint.NAME
            puts("\n- Name specified in blueprint.py: {0}".format(colored.yellow(name)))
            settings.config["project_templates"].append({"name": name, "url": template_url})
            settings.save()

        except AttributeError:
            name = template_url.split("/")[-1]
            error = "\n- No name specified in blueprint.py, using '{0}'".format(colored.yellow(name))

It returns the misleading error, "No name specified in blueprint.py." The actual error is that git is undefined.

[eyeseast]

Thanks for flagging this. Lots of error codes could be better here. I'll make sure this gets added to the installation instructions.

[ghing]

Also, this could be mitigated by using libgit instead of the git cli. See #399.

[eads]

#399 would be great to pursue. Things have gotten better in terms of git - python integration than they were four years ago!

…

On Wed, Jun 21, 2017 at 3:48 PM, Geoffrey Hing ***@***.***> wrote: Also, this could be mitigated by using libgit instead of the git cli. See #399 <#399>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#439 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAmuzA-o69gmCh1gflyuXrvVVQPZ8cu4ks5sGXOQgaJpZM4LvKC0> .

-- David Eads | http://recoveredfactory.net "Medical statistics will be our standard of measurement: we will weigh life for life and see where the dead lie thicker, among the workers or among the privileged." -- Rudolf Virchow

[eyeseast]

Let me open a small can of worms here: Could we abstract out blueprint downloading so that git isn't a hard requirement?

In a typical workflow (based on my team's usage), git is being used (by Tarbell) to clone a blueprint when I first create a project. Once the initial setup is done, we're using git on the command line for normal version control things, but we're (usually) not touching the blueprint. If Tarbell downloaded a zip file and unpacked it to _blueprint, it wouldn't make any difference in most projects.

Advantages to this:

• Python's standard library can deal with zip and gzip compression, so fewer external dependencies.
• It would work on Windows.
• It opens a path to having blueprints stored on other version control systems.

Disadvantages:

• Tarbell would need to figure out what type of blueprint it's dealing with (file, git, compressed or not, etc), much like pip does.
• Probably lots of other things I'm not thinking of. Like I said, can of worms.

[ghing]

I don't feel strongly about any of this, and TBH, don't use Tarbell much these days, but wanted to capture my thoughts on this somewhere.

This feels like a can of worms for sure, but I understand the motivation.

This statement:

Tarbell would need to figure out what type of blueprint it's dealing with (file, git, compressed or not, etc), much like pip does.

This question lead me to think, "why not just make Blueprints Python packages?" so packaging software, like pip, can be leveraged to iron out the differences between sources.

However, Python packaging can be such a pain, even for people who have done it. So I wouldn't say this is a great solution. I could, however, imagine a migration tool that helps turn an existing blueprint into a package.