Extract egg/package name from URLs.

[ampledata]

Added conditional to check for and extract egg/package name from URLs.

Fixes #84.

[coderanger]

This is where reimplementing pip starts to suck, you can have both egg and md5 tags in a package URL :-(

[ampledata]

Ok, I could build a more complex rex to address this, would that suffice?

[coderanger]

@ampledata I'm trying really hard to avoid this stuff as much as possible because it is going to result in reimplementing large swaths of pip in Ruby.

[coderanger]

/cc @qwcode @dstufft

[ampledata]

I understand, I believe you, I'm just trying to fix a bug. One bug at a time, that's what the 12-step folks say, right?

[dstufft]

So uh, why are you reimplementing pip in ruby

[coderanger]

@dstufft Given a "package name" that is actually a URL we need to get its real name to check its version to know if we need to actually call pip :-(

[dstufft]

specifically an url, or any requirement?

[ampledata]

@dstufft #84

[coderanger]

@dstufft The more the merrier, but this patch specifically addresses a URL with #egg=

[coderanger]

Part of the issue is that git-based requirements are kind of inherently not idempotent in any useful way

[dstufft]

Right, I'm just trying to think if there's a better way than reimplementing pip, because the rules of #egg are not deterministic and trying to parse that will be painful if you want to cover all the cases.

[coderanger]

@dstufft can haz pip --dryrun? :)

[qwcode]

if it's a vcs url, there's no supported use of a hash fragment, right?, and pip's vcs urls start with [git|hg|bzr|svn]+, so they can be distinguished from archive urls.

yes, #egg can potentially be anything the user puts there, although it's intended to signal the project name for dependency resolution (it can be "name" or "name-version"). Btw, I recently had the idea of dropping the #egg= syntax at some point (pypa/pip#1289), but on second thought, maybe an identifier should always remain, even it's fragile. not sure atm.

as for the dry run idea to determine the spec for real... although I rarely use --target, one thought is pip install --ignore-installed --target=<target dir> which allows you to install something off the pythonpath, and then if pip freeze were run in the context of PYTHONPATH=<target dir>, it would report the real requirement spec for whatever was in the vcs install. it would be slow though. I don't know how fast this routine is supposed to be.

[qwcode]

btw, I know this is chef-world, but I was recently tasked with creating a puppet virtualenv module that supported requirements files and all of pip's requirement forms (package specifiers, vcs urls, pkg urls), and in order to NOT recreate pip in ruby, the path we've taken for now is to create custom ruby types that simply wrap a python module (that internally uses pip and pkg_resources, pip freeze wasn't enough). similar to puppet's yum provider that wraps a python yumhelper module.

[coderanger]

@qwcode Yeah, see https://github.com/coderanger/python-cookbook/blob/master/libraries/package.rb#L32-L45. It is very :-( though.

[coderanger]

This is now better handled by the python_requirements resource in https://github.com/poise/poise-python.