Log file Viewer

[00:10:32] <victorvpaulo> Hello! I am trying to reproduce locally some test fails that occurred when the CI tool tested my PR, but i have not been able to run tests locally - there seems to some issues in my testing environment. Is there any resource about building a local pip test environment?

[01:12:26] <pradyunsg> toad_polo: thanks for the heads up.

[01:13:22] <pradyunsg> victorvpaulo: Hi! Welcome.

[01:15:10] <pradyunsg> victorvpaulo: I understand that you trying to run the pip test suite and having trouble getting it working. Correct?

[01:16:54] <pradyunsg> victorvpaulo: Could you be more specific about why you believe that you are not able to run the tests locally? If you have some error message, it'd be helpful if you share it here.

[01:27:52] <victorvpaulo> Correct. The problem is that some tests fail even if they are run against my local clone of pip master branch (the local clone is in the same state as the upstream branch).

[01:34:53] <victorvpaulo> For instace: When i run <tox -e py27 tests/functional/test_install_reqs.py -- -k "not (svn or hg or bzr)" > i get a test failure message like this one: https://gist.github.com/victorvpaulo/b13505eeef9f70f6176638c479e5f668

[01:36:28] <victorvpaulo> When i run the same test, but for python3.6 (tox -e py36), i get a message saying that all tests passed.

[01:44:10] <victorvpaulo> I need to make the tests pass for python 2.7 because the PR i opened today is about allowing the user to silence warning about python 2.7 deprecation, and the PR failed to pass all checks for python 2.7 on Windows.

[02:01:16] <victorvpaulo> Without passing the tests against the a "clean" version of pip master branch i can't test my commit.

[06:36:13] <omry> I found a crazy and ancient bug in setuptools. if a package have - in the name, setup tools will add phantom a phantom package without the suffix (assuming the suffix is a version).

[06:36:29] <omry> If there is an actual package without the suffix, it will get matched to the phantom package.

[06:36:42] <omry> example package names: foo-bar and foo (which is a typical scenario with plugins)

[06:36:59] <omry> code creating the phantom packages: https://github.com/pypa/setuptools/blame/1cc88214f605e8458cc45495e6a8f476ad6d1cbb/setuptools/package_index.py#L172-L182

[06:37:32] <omry> someone trying to install foo, might actually be matched to foo-bar.

[11:04:56] <toad_polo> omry: Presumably that's a bug in easy_install?

[11:06:04] <toad_polo> There are a ton of those. We generally ignore them, as the solution is usually to get people to use a command that simply doesn't hit that code path.

[11:07:04] <toad_polo> PEP 517 and pip together are usually enough to avoid ever hitting easy_install. Hopefully soon we'll be able to properly deprecate it.

[12:43:35] <ronny> agronholm: are there any plans to put in cythonish helpers into cbor2? (or anything preventing a contribution for that where i to experiment with it)

[14:25:04] <omry__> toad_polo, is easy install the code path hit when people do python setup.py install ?

[14:27:43] <omry> specifically the actual use case I have is installing dependencies (and even transitive dependencies) from a private githup. is there a way to avoid that code path for this?

[14:28:11] <omry> * private github repo. (over git+ssh).

[14:35:44] <omry> toad_polo, also - unfortunately my solution should work for python 2.7 as well, which probably excludes PEP 517.

[16:22:22] <ronny> omry: simply always use pip install, never use setup.py install

[16:24:21] <omry> ronny, this goes for setup.py develop (pip install -e), right?

[16:24:45] <omry> are setuptools install and develop deprecated?

[16:26:31] <ronny> omry: they are discouraged, as they basically do a egg style install when using setuptools

[16:27:15] <ronny> modern setuptools has a pip-517 backend, and that will hopefully sort out the issues, as far as i understood, currently pip hasa backport to python2.7

[16:31:01] <omry> testing with pip install

[16:35:06] <omry> ronny, is there a pip uninstall . ?

[16:46:11] <omry> okay, pip install works both for -e and normal, under python 2.7 and 3.6.

[16:46:37] <omry> if setup.py develop and install are discouraged, why not print some warning to direct people to use the encourages alternative?

[16:46:49] <omry> * encouraged

[16:47:29] <sumanah> https://pip.pypa.io/en/stable/reference/pip_uninstall/ omry

[16:48:52] <omry> sumanah, I got that. would be good if install and uninstall supported the same specification. pip uninstall . should do the opposite of pip install .

[16:50:38] <sumanah> omry: I don't know enough to help you here, sorry - there are definitely open issues like https://github.com/pypa/pip/issues/6703 and https://github.com/pypa/pip/issues/4805 about pip uninstall

[17:00:50] <omry> thanks sumanah, what I am asking for is more of an enhancement than a bug. it seems like missing functionality. maybe there is a good reason for it, but as a user I expected it to work.

[17:31:05] <toad_polo> omry: PEP 517 is unrelated to 2.7

[17:34:38] <toad_polo> omry: We are definitely planning on raising deprecation warnings for all direct `setup.py` invocations, but we need to build all the replacements and make sure people aren't hit with erroneous deprecation warnings from tools like pip doing invocations behind the scenes.

[18:38:03] <ronny> agronholm: forget what i wrote, i mussunderstood the readme and just stumbled uppon the c impl