Log file Viewer

[00:22:10] <ronny> Method__: without a sat solver, a upgrade all function makes no sense

[00:22:29] <Method__> ...what not

[00:22:34] <Method__> what's a "sat solver"

[00:22:56] <Method__> !logs

[00:22:56] <pmxbot> http://chat-logs.dcpython.org/channel/pypa

[00:23:05] <ronny> Method__: a sat solver is a powerfull backtracing dependency resolver that can atempt different dependency trees until a conflict-free solution is found

[00:24:04] <ronny> dstufft: is there any token mechanism for pypi to do automated uploads?

[00:24:07] <Method__> ok, how would having that make an upgrade all function make more sense?

[00:24:25] <Method__> rather than go: pip install every, single, dependancy, on, this, box -U

[00:24:38] <Method__> just, pip install --upgradeallthethings

[00:24:55] <ronny> Method__: pip install -U leafpackage does update dependencies

[00:25:11] <ronny> Method__: however jsu updating all pacakges does not ensure a correct dependency tree

[00:25:22] <Method__> hm

[00:25:35] <ronny> an update of package X might need a downgrade of pacakge Y due to a bugfix via a dependency constraint

[00:25:44] <ronny> for example if a new library version has a bug

[00:26:12] <Method__> I see

[00:27:18] <ronny> also there is fun brakage modes like too a needs library Y 2.x and tool be needs library Y 3.x

[00:28:01] <dstufft> ronny: no, just passwords

[00:28:42] <ronny> dstufft: oh :/

[00:29:05] <ronny> dstufft: i want to create a travis setup for setuptools_scm

[00:29:21] <dstufft> make a second account and store that password

[00:29:57] <ronny> dstufft: will warehouse support tokens?

[00:30:05] <dstufft> not immediately

[00:30:17] <dstufft> something like that is planned in the future though

[00:43:37] <ronny> dstufft: got a rough estimate?

[00:43:53] <dstufft> of when we'll have token support? not a clue

[00:44:02] <ronny> i see

[03:33:52] <kenny> I'm getting an SSL error when creating a venv unless I use `--no-download`. Anyone know why. "SSLError: [Errno 20] Not a directory"

[03:39:06] <dstufft> kenny: which version of virtualenv

[03:42:23] <kenny> dstufft: 14.0.1. I think it might be related to some tests I'm trying to get running though. As if I uninstall and reinstall it it works again.

[03:42:42] <kenny> trying to see what they changed now

[03:49:39] <sbraz> hi, i haven't gotten an answer so i'll try again :)

[03:49:40] <sbraz> 15:14 < sbraz> hello, is it possible to take over someone's project on pypi if he isn't replying to my messages and/or maintaining the package?

[03:49:43] <sbraz> 15:15 < sbraz> the package i'm thinking of is https://github.com/paltman-archive/pymediainfo

[03:49:46] <sbraz> 15:15 < sbraz> i made quite a big patch for it and asked the maintainer if he was willing to merge it but i have not received a reply

[03:49:49] <sbraz> 15:15 < sbraz> since it's in a repo called "archives", i'd say it's mostly dead

[04:10:18] <kenny> Well, I think it's certificate related, and it seems to change depending on the time. I think I can get it working with the pip._vendor.requests.certs setting

[17:51:51] <sbiff> Hey guys and gals

[17:52:12] <sbiff> If there a safe way to get the .data directory for a package that was installed with pip wheel?

[17:52:17] <sbiff> *is

[18:44:09] <rtgibbons]tcu]> Looking for information on installing applications in a global manner while maintaining virtual environments - I'm looking at https://github.com/mitsuhiko/pipsi but wondering if there are other options

[19:22:04] <nedbat> anyone willing to take a look at a failing appveyor build? It looks like pip 8.0.2 isn't able to download setuptools for 2.7?? https://ci.appveyor.com/project/nedbat/coveragepy/build/job/9e1k581ebxv38da9

[19:55:15] <exarkun> is there a trick for "pip install using wheels from the cache and building wheels for non-cached packages and also updating the cache with those builds"

[19:55:44] <exarkun> Or, at a higher level, a trick for being able to avoid having to build all the packages on travis-ci

[19:56:31] <exarkun> (without having to construct a thing to track changes to a project's declared requirements)

[20:25:00] <dstufft> exarkun: I'm not sure what that means... you just want to cache build artifccts for dependencies?

[20:25:04] <dstufft> is that what you're hoping for?

[20:28:17] <exarkun> Sure, yea. Though, specifically, cache them so that I can use them in setup for future jobs (not just for the sake of having an up-to-date cache of them).

[20:29:12] <exarkun> (maybe that's obvious)

[20:31:37] <dstufft> exarkun: ensure you're on pip >= 7.0, ensure you have the "wheel" package installed, then cache the ~/.cache/pip directory (assuming Linux)

[20:32:13] <dstufft> then just use ``pip install`` as nromal

[20:32:15] <dstufft> normal

[20:33:13] <dstufft> that will A) anything that is already a wheel on PyPI, will be cached locally in ~/.cache/pip/http as an HTTP cache for essentially forever (I think it's 10 years?), anything that is an sdist on PyPI will have a wheel built implicitly, and placed in ~/cache/pip/wheels which will be reused in place of said sdist in the future

[20:35:40] <dstufft> nedbat: I don't know how to use appyeyor, that look slike a mostly blank page to me that says something about Pytohn 3.2

[20:38:03] <nedbat> dstufft: sorry, what about this? https://ci.appveyor.com/project/nedbat/coveragepy/build/default-255/job/jvv5l8vxwtcn2f2e

[20:38:19] <nedbat> line 331 in particular: https://ci.appveyor.com/project/nedbat/coveragepy/build/default-255/job/jvv5l8vxwtcn2f2e#L331

[20:40:32] <dstufft> oh

[20:40:33] <dstufft> heh

[20:40:36] <dstufft> I know what the problem is

[20:40:48] <ionelmc> someone patched the vendored requests

[20:40:57] <dstufft> No

[20:41:04] <dstufft> this is legit myfault

[20:41:39] <ionelmc> i wonder why requests raise exceptions without original traceback

[20:42:37] <dstufft> nedbat: gimme a minute

[20:43:20] <nedbat> dstufft: you probably don't need to be told this, but this is now happening randomly on my laptop as well.

[20:43:38] <dstufft> yea, I borken a virtualenv

[20:43:56] <dstufft> I am not smart

[20:45:01] <nedbat> dstufft: do you think it's fixed now?

[20:45:09] <dstufft> No

[20:45:14] <ionelmc> well what's the problem

[20:45:19] <dstufft> I need to make a new virtualenv

[20:47:34] <ionelmc> nedbat: you virtuous man you!

[21:06:31] <exarkun> dstufft: Thanks. "Upgrade to pip>=7.0" seems to have been the main thing I was missing.

[21:09:53] <dstufft> nedbat: This: https://github.com/pypa/pip/pull/3420 + a new virtualenv including that should fix

[21:10:22] <nedbat> dstufft: you're saying we need an 8.0.4?

[21:10:32] <dstufft> 8.0.3 but yea

[21:10:42] <nedbat> ok

[21:10:57] <dstufft> virtualenv adds the zipped up wheel to the PYTHONPATH then imports pip and does an install

[21:11:05] <dstufft> that worked fine before becasue we always ran with --no-index

[21:11:48] <dstufft> but virtualenv 14 doesn't run with --no-index by default, so pip has to verify a SSL certificate

[21:11:59] <dstufft> and openssls API expect said certificate to exist on the FS

[21:12:50] <ionelmc> dstufft: why --no-index anymore?

[21:13:13] <dstufft> ionelmc: wsa that supposed to be "why not --no-index anymore" ?

[21:13:49] <ionelmc> dstufft: you read my mind

[21:15:35] <dstufft> ionelmc: My belief is that what most people actually want is the latest version of pip, I've seen numerous people who the first thing they do after they create a virtualenv is upgrade the preinstalled libraries, thus defeating some of the point of preinstalling them to begin with. Combine that with things like virtualenv on 3.5 being broken for awhile because the version of wheel we bundled didn't support 3.5 and it seems to be a saner default

[21:15:35] <dstufft> to pull down the latest version by default

[21:16:01] <dstufft> that was actually what virtualenv used to do, backwhen it executed ``python setup.py isntall`` instead of using pip to install itself

[21:16:26] <dstufft> but it was removed because we couldn't securely download the latest version inside of virtualenv without doing a bunch of the same work as in pip

[21:16:37] <dstufft> but since then, we've switched to using pipt o isntall itself, and pip knows how to securely download itself

[21:16:50] <dstufft> so we've gone back to installing the latest version by default

[21:18:16] <dstufft> as far as a work around

[21:18:31] <dstufft> nedbat: if you use --no-download when you create the virtual environment, then you should work fine

[21:19:03] <ionelmc> dstufft: also, gave up on the rewrite idea completely?

[21:19:16] <dstufft> Nope, just haven't had time

[21:19:31] <dstufft> my TODO list is a mile long :/

[21:22:28] <ionelmc> backporting changes ain't really my thing

[21:22:56] <ionelmc> and the list of changes is getting rather long

[23:28:02] <kober> Hey, I'm trying to have my setup.py grab a file thats sitting relative to it (assets/manifest.json) and I have in my MANIFEST.in include assets/manifest.json but when I run `python setup.py sdist` it says: "'assets/manifest.json' not a regular file -- skipping

[23:28:25] <kober> What is a "regular" file and how to I tell it to include my file even if it doesn't think its regular?

[23:28:42] <ionelmc> kober: is it a symlikn or something?

[23:30:29] <kober> According to file its just a plain text file (I can cat it) "assets/manifest.json: ASCII text" and its not a symlink