PMXBOT Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Tuesday the 22nd of September, 2015

(Back to #pypa-dev overview) (Back to channel listing) (Animate logs)
[06:03:06] <tchaypo> excellent
[06:03:20] <tchaypo> xafer: have you filed a bug already?
[06:03:42] <tchaypo> (he asks, 8 hours later)
[06:11:33] <xafer> Not yet, I was sleeping
[09:30:29] <xafer> this PR (#3126) fix most of the errors
[09:31:58] <xafer> test_install_user_in_global_virtualenv_with_conflict_fails failure might come from pytest 2.7.3 -> 2.8 but seems unrelated (diff between https://travis-ci.org/pypa/pip/jobs/80865519 and https://travis-ci.org/pypa/pip/jobs/81228068)
[09:37:52] <xafer> test_install_from_local_directory_with_symlinks_to_directories failure might come from pytest 2.7.2 -> 2.7.3 (maybe """optimized tmpdir fixture initialization, which should make test sessions faster (specially when using pytest-xdist). The only visible effect is that now pytest uses a subdirectory in the $TEMP directory for all directories created by this
[09:37:52] <xafer> fixture (defaults to $TEMP/pytest-$USER). Thanks Bruno Oliveira for the PR.""") - diff between https://travis-ci.org/pypa/pip/jobs/80320175 and https://travis-ci.org/pypa/pip/jobs/80497767
[16:54:30] <willingc> dstufft: For updating packages using current version of pip, a user (whether using Python 2 or 3) can update using pip. No pip3 is needed. Correct?
[16:56:14] <dstufft> willingc: not sure I understand the question
[16:56:22] <dstufft> pip is tied to a specific Python
[16:56:58] <dstufft> it's best if you stop thinking of the ``pip`` command, and instead use ``python -m pip``, and any changes are tied tot hat specific version of python
[16:57:32] <willingc> I'm writing docs for a user to update Jupyter/Ipython notebook. Users might be using an older version of pip or newer version. Some folks wish to document pip3 for Python 3 and pip for python 2.
[16:57:56] <willingc> I use pip for python3 all the time.
[16:58:19] <dstufft> it depends on how you installed your pip and in what order what ``pip`` will point to
[16:59:27] <willingc> Ahh... Is it better to recommend ``python -m pip install --upgrade packagename``
[16:59:58] <dstufft> yea
[17:00:11] <dstufft> We're debating deprecating the ``pip`` commands all together
[17:00:17] <dstufft> only reason not to is backwards compat
[17:00:19] <willingc> Will that work if say someone does not have the current pip version
[17:00:25] <dstufft> yes
[17:00:26] <dstufft> but
[17:00:29] <dstufft> it won't work on Python 2.6
[17:00:39] <dstufft> you need python -m pip.__main__ for that :/
[17:00:46] <willingc> But it will work on pip 6.xx
[17:00:53] <dstufft> yes
[17:00:59] <dstufft> it'll work on uh, every pip ever I think
[17:01:03] <willingc> you are amazing
[17:01:06] <willingc> thanks
[17:01:14] <dstufft> no problem
[17:01:26] <willingc> Let me know if you want me to add to pip docs too
[17:03:06] <dstufft> I think Python 2.6 is the big sticking point for unequivocally trecommending ``python -m pip``
[17:15:10] <ErikRose> ^ That's just a little something I ran into while jimmying some test cases for the hashing.
[17:15:23] <ErikRose> Looks like just an old capitalization error.
[17:16:05] <ErikRose> Actually, it'll be interesting to see if it reveals any broken tests. :-)
[17:19:21] <dstufft> I think our tests might be broken in general right now
[17:19:27] <dstufft> from new versions of pytest
[17:20:29] <ErikRose> Well, the build *is* failing...
[17:21:31] <xafer> https://github.com/pypa/pip/pull/3126 should fix the virtualenv change
[17:22:06] <xafer> i.e. the errror "TypeError: unsupported operand type(s) for -: 'str' and 'str'"
[17:22:50] <ErikRose> That would be lovely. *looks at why that PR's tests are still failing*
[17:23:13] <ErikRose> Certainly looks like an improvement.
[17:25:19] <xafer> the rest might be related to py.test changes (or not) but py.test version changed between the last passing build and the first fail I think
[17:54:27] <xafer> I did not merge it because the change came from virtualenv but virtualenv supporting the Path object seemed to be luck so explicitly casting the str to Path seems like the right thing to do...
[21:41:30] <ErikRose_> xafer++
[21:45:19] <xafer> any clue for the 2 other tests ?
[21:49:25] <ErikRose_> Wild guess for test_install_from_local_directory_with_symlinks_to_directories: is it surprised to be comparing a Path against a set of strings in TestPipResult.files_created?
[21:49:45] <ErikRose_> I don't have all that loaded into my head right now.
[21:50:58] <ErikRose_> The INITools failure at https://travis-ci.org/pypa/pip/jobs/81545046 is a probably-transient network timeout, obviously.
[21:52:11] <ErikRose_> Yeah, I think both the other ones are due to INITools fetching failures.
[21:52:21] <ErikRose_> ^ xafer
[21:55:20] <xafer> well for test_install_from_local_directory_with_symlinks_to_directories file_created appears to be empty (assert Path('venv/lib/python2.6/site-packages/symlinks') in {} where {} = <tests.lib.TestPipResult object at 0x126fe10>.files_created)
[21:58:01] <ErikRose_> xafer: If files_created tracking just plain didn't work with Path involved, I'd expect a lot more tests to fail.
[21:58:13] <ErikRose_> So I don't know; I guess it's an afternoon in the debugger for somebody.
[22:14:58] <xafer> Well if any pytest user could take a look at the https://travis-ci.org/pypa/pip/jobs/81674361 failures, it would be very helpful ^^
[22:15:44] <xafer> As a reminder, test_install_from_local_directory_with_symlinks_to_directories failed between https://travis-ci.org/pypa/pip/jobs/80320175 and https://travis-ci.org/pypa/pip/jobs/80497767 (so unrelated to any pip code change) and test_install_user_in_global_virtualenv_with_conflict_fails failed between https://travis-ci.org/pypa/pip/jobs/80865519 and
[22:15:44] <xafer> https://travis-ci.org/pypa/pip/jobs/81228068 (so likely unrelated to any pip code change also)