Chokes on a package dependency which can't be found but has just been installed

[jwg4]

Hi there, thanks for this great tool.

If I have a requirements.txt which contains two packages, and one of them is a URL of a download which isn't on pypi:

http://internal/packages/bar_1-0.tar.gz
foo=1.0

Installing these requirements into a virtualenv using Terrarium fails, it seems because:
If foo has a dependency on bar, then installing foo will fail because it doesn't know how to find the package bar, even though it has just been installed from the URL.

By contrast, pip will realize that bar is already present, and not worry about finding it.

[winhamwr]

Hi jwg4,

Thanks for creating an issue!

To clarify, you see this behavior when creating a virtualenv from scratch, right? So it sounds like maybe this has something to do with packages distributed outside of pypi via tarballs, perhaps?

here is the command that terrarium uses to run pip. Perhaps one of the options modifies the behavior that you normally see?

To maximize the chance of getting a fix for this merged in, would you be willing to create a failing testcase? this test is a good place to start. Basically, it sounds you'll want to self._add_requirements(...) to',add a tarball requirement and then again to add a requirement for a package that depends on that tarball.

Thanks
-Wes

[jwg4]

I have done the second task of creating a test case, in #59 Let me know if there are any queries or changes required.
I haven't yet been able to figure out where the invocation of pip differs to what one would normally do as a pip user. I will look at this a bit more.

[jwg4]

#59 now has a fix as well as a test case.

[jwg4]

This fix is a year old. Terrarium was a great concept, but you should warn people in the README and the docs that it is unmaintained.

[jlward]

Hello jwg4

Sorry we haven't had a chance to look into this in the past year. The reason we are sorting the reqs is so that if all you have done is re-order the reqs in requirements.txt file, the generated hash is not different. #59 will fix the bug outlined in this issue, while also breaking the hash if the order is the only thing that has changed. I have reached out to the other devs for this project and hopefully one of them will be weigh in with determining if breaking the hash is alright. Thanks so much for the PR and sorry if it seems we are not maintaining this project. We will try to be better about PRs in the future.

Jason

[kylegibson]

#59 was merged in