Local project path support for virtualenv target. (re:#947)

[josephholsten]

rebased #947, I'm skeptical this actually works.

Note: apparently I rebased this badly.

It would also be awesome to have @vi4m review this, I don't really know how all these flags interact.

[josephholsten]

needs a test

[jordansissel]

Assuming I'm understanding this correctly, I have a proposal (tell me if I am off-base)

This PR adds a new flag to enable tell fpm a local project path, but what if instead of a new flag, we do what the python and gem support does in fpm which is to check if the given argument (target_args in this scope?) is a local path. If it is a local path, we use that the same way as intended by this PR. If it is not a local path, then we use the existing behavior?

The end result would be nearly the same for the user with the exception that we wouldn't need to add a flag to achieve it. Thoughts?

[josephholsten]

is it possible for a file check to be ambiguous in that case? there being a ./foo directory and a foo package? is that a concern?

[jordansissel]

I think it's possible to have ambiguity, but maybe unlikely.

Like if you are doing python and you have a directory named simplejson and you try to do fpm -s python -t rpm simplejson then fpm is going to try and look for simplejson/setup.py because that directory exists. Ambiguity becomes a problem if your package name you intend to download is the same as the name of a directory in your current directory.

Here's examples of where fpm tries to be clever about what the input arguments mean, and I think it succeeds:

gem source does this: https://github.com/jordansissel/fpm/blob/master/lib/fpm/package/gem.rb#L80-L88

• If the given argument is a file that exists, use that file. If it does not exist as a file, ask rubygems for the gem by name.

python source does this: https://github.com/jordansissel/fpm/blob/master/lib/fpm/package/python.rb#L110-L149

• If the given argument is a directory, assume <arg>/setup.py. If the argument is a file named setup.py, use that path. Otherwise, ask pypi for the package named <arg>.

From what I can remember, both of the above (gem and python) strategies have served users well without being confusing. I might be remembering incorrectly, though.

That said, I think it's probably OK to take a similar strategy here where we use the argument as a path if that path looks like a reasonable thing to tell virtualenv about, and if it isn't, then we fetch things from pypi directly.

Thoughts?

[josephholsten]

+🌮

[beddari]

I fully support @jordansissel proposal and it is perfectly inline with what I'd expect as a user.

[jordansissel]

(sorry, didn't mean to delete this branch)