pmxbot IRC Log Viewer

[11:10:05] <straycat> Is there a spec for names on pypi? I've been looking for one but can't see one

[11:22:05] <xafer> straycat, I dont think so, maybe http://legacy.python.org/dev/peps/pep-0426/#name

[11:22:34] <xafer> (but it's still a draft)

[11:23:47] <straycat> ahh okay thanks

[15:20:26] <davidszotten> hi. do i understand correctly that --index-url specified in a requirement file overrides any --index-url specified on the command line? is this intentional?

[15:33:16] <xafer> from https://github.com/pypa/pip/blob/develop/pip/req/req_file.py#L81-L82 I understand the same thing but would not consider it a good idea :o

[15:36:18] <xafer> same with --no-index :o

[15:44:09] <apollo13> dstufft: wow, the new virtualenv looks nice

[15:45:10] <dstufft> apollo13: thanks :) hopefully it turns out well or it'll be a bunch of wasted effort ha

[15:45:24] <dstufft> I think I can say for sure the new archiecture works though

[15:45:43] <dstufft> (instead of re-executing the script, jsut calling into the target python to inspect some details)

[15:54:01] <apollo13> yeah, saw that

[15:54:06] <apollo13> it will be fine :)

[15:57:36] <apollo13> dstufft: should I set my pip wheel dir to my cache dir or something else?

[15:58:13] <dstufft> apollo13: well ~/.cache/pip/http won't use anything from it, we don't have a general solution for wheel caching yet, so whatever you like really

[15:59:31] <tomprince> ~/.cache/pip/wheel ?

[16:00:56] <apollo13> tomprince: yeah that is what I just did

[16:03:05] <apollo13> dstufft: so if I have an index (pypi) and find-links what will be prefered?

[16:03:25] <apollo13> looks like the index

[16:03:34] <apollo13> ah wait forgot find-links

[16:04:14] <apollo13> MissingSchema: Invalid URL u'~/.cache/pip/wheelhouse': No schema supplied. Perhaps you meant http://~/.cache/pip/wheelhouse?

[16:04:15] <apollo13> ahahaha

[16:05:29] <dstufft> apollo13: um, depends

[16:05:34] <apollo13> ah perfect, find-links to the wheeldir works

[16:05:44] <dstufft> apollo13: I think indexes are preferred, but the rpeference thing goes like

[16:05:58] <dstufft> Version > Wheel > Sdist > What Location it comes from

[16:06:00] <apollo13> na indexes are not prefered *hmm*

[16:06:31] <dstufft> so a higher version number is always better, and a wheel is always better than a sdist, and what location it comes from is the least important thing we care about

[16:06:45] <apollo13> perfect

[16:06:53] <apollo13> so can I enable pip wheel by default?

[16:06:56] <apollo13> (for install)

[16:07:23] <dstufft> apollo13: it won't build wheels and cache them if you do ``pip install`` no

[16:07:37] <apollo13> that would be a great feature :)

[16:07:49] <dstufft> yea, it's planned, but it requires more refactoring of pip

[16:07:56] <dstufft> and is probably going to break some things

[16:08:13] <dstufft> like older Django's and some django-* projects which copied things from Django's old setup.py

[16:08:38] <apollo13> I don't care :)

[16:08:55] <apollo13> I'll just run pip wheel -r from now on followed by install

[16:09:21] <apollo13> only thing when that can break is if someone reuploads a version to pypi instead of issuing a new release

[16:09:26] <apollo13> but then I'll hunt em down

[16:11:00] <dstufft> apollo13: that isn't going to be possible much longer

[16:12:57] <dstufft> apollo13: once I get around to writing the code to make it happen, PyPI is going to switch to a "once you release a version, you can't re-release it with different contents" model

[16:30:57] <tdsmith> looking at the distutils-sig archive, adding sha256 checksums to the pypi json api is expected someday but there's not a date, right?

[16:34:13] <dstufft> tdsmith: correct, mostly it's waiting on devpi to fix themselves so that removing md5 won't break them, though probably we can add the sha256 sums to the json api in th emean time

[16:36:50] <apollo13> dstufft: btw regarding the discussion about oids and tables without pk earlier, is the current pypi running still some kind of legacy or a warehouse spinoff

[16:39:26] <apollo13> also, as for oid as pk, you know that they are not unique right?

[16:43:06] <dstufft> apollo13: pypi.python.org is pypi-legacy, basically the same code it's always run (though we've added/improved bits and pieces), warehouse.python.org is running warehouse

[16:43:15] <dstufft> both are backed by the same database and package files

[16:43:32] <apollo13> and wharehouse is used by whom?

[16:43:46] <apollo13> or rather what is the goal of warehouse

[16:44:31] <dstufft> warehouse.python.org is a demo site for the new warehouse code, the warehouse code, once it's got enough functionality, is going to replace the legacy code and move to pypi.python.org (at which point we'll redirect warehouse.python.org -> pypi.python.org)

[16:45:53] <apollo13> so if I want to see how many problems we'd have with django I'd look at the schema defined in warehouse cause that would be up2date anyways

[16:46:41] <tdsmith> dstufft: cool, thanks. would use sha256's if i had 'em but have a low-pain workaround in place

[16:47:18] <dstufft> apollo13: warehouse doesn't have the entire schema mapped yet, only the parts we've used in warehouse so far

[16:47:34] <dstufft> there's a schema dump though somewhere

[16:50:08] <apollo13> dstufft: mind mailing that to me if you find it somewhere

[16:53:56] <dstufft> apollo13: I think https://bitbucket.org/pypa/pypi/src/3f152fc78f36784ed8c3cecce050c46779a9c939/pkgbase_schema.sql?at=default has it, I don't think it's actually out of date i'm pretty sure that's jsut a warning because we aren't being super vigilant about keeping it upt o date

[16:54:04] <dstufft> I can probably get a santizied dump of the data too

[16:54:26] <apollo13> na, no need to do more work than necessary

[16:54:33] <dstufft> (you can see the accoutns_email and accounts_user table left over from the last time I tried to get Django reading the schema)

[16:54:54] <apollo13> thanks!

[17:03:37] <apollo13> dstufft: was that before custom user models?

[17:03:45] <dstufft> ummm

[17:03:48] <dstufft> might have been

[17:03:58] <dstufft> I don't remember

[17:04:23] <dstufft> user accounts should totally work with django though

[17:04:36] <dstufft> except maybe the password don't work, I don't remember if passlib and django are compatible

[17:05:01] <apollo13> not really I think

[17:05:40] <apollo13> okay, I think I have to read the source code to understand what mainindices and subindices are^^

[17:06:04] <dstufft> which table

[17:06:17] <apollo13> cheesecake_subindices

[17:06:24] <apollo13> and cheesecake_mainindices

[17:06:59] <dstufft> oh

[17:07:01] <dstufft> you can ignore those

[17:07:06] <dstufft> cheesecake shit isn't used anymore

[17:07:17] <dstufft> we should probably delete them

[17:08:40] <apollo13> interesting, nothing in the packages table is unique, how do you decide what is winning?

[17:09:44] <apollo13> is all the validation handled in the frontend?

[17:10:24] <apollo13> oh index creation is at the end, I should import that into postgres instead^^

[17:10:29] <apollo13> sorry

[17:24:03] <apollo13> dstufft: does that dump miss triggers or similar or is for instance comments_journal no longer used?

[17:24:16] <dstufft> comments_journal isn't used anymore

[17:24:29] <apollo13> ah, admin.py has still an update for it ;)

[17:25:00] <apollo13> can you get me a list of no longer used tables before I throw inspectdb over it ;)

[17:26:34] <dstufft> I don't have an exhaustive list, I just know some of them

[17:26:51] <apollo13> mhm

[17:26:56] <dstufft> part of warehouse was only making SQLAlchemy schema stuff for the tables we needed

[17:27:08] <dstufft> and then once I was done doing that I was going to just delete anything else

[17:27:11] <apollo13> yeah but that still leaves me with uncertainty :)

[17:27:35] <apollo13> the table dual looks interesting, reminds me of oracle

[17:27:59] <dstufft> yea

[17:28:15] <dstufft> I don't have a better answer without going through and looking at each table which I can't do right this minute

[17:28:36] <apollo13> no worries, could you put it on your todo?

[17:28:47] <dstufft> yea

[17:28:50] <apollo13> I might be without much to do in march/april

[17:29:20] <tomprince> pip 6.0.6 is printing a bunch of empty lines when installing at least somethings.

[17:29:41] <apollo13> tomprince: and somethings equals what?

[17:30:34] <tomprince> pip install -e '.[dev,release]' on the branch of https://github.com/ClusterHQ/flocker I am working on.

[17:30:50] <tomprince> It seems like maybe one for each wheel it installs?

[17:30:54] <dstufft> empty lines is interesting

[17:31:04] <tomprince> (not a very good report, I know)

[17:31:24] <dstufft> wonder if that sa side effective of moving some things from info to debug logging levels

[17:31:30] <dstufft> maybe there's some new lines that need removed somewhere

[17:33:22] <Alex_Gaynor> I definitely have seen the empty lines thing

[18:02:11] <kennethreitz> is pip 6.0.6 intentional?

[18:02:30] <Alex_Gaynor> What about it?

[18:02:46] <kennethreitz> major version bump, when i upgraded to it things broke

[18:02:50] <kennethreitz> haven't looked into it further yet :)

[18:03:09] <dstufft> kennethreitz: what broke?

[18:03:19] <kennethreitz> pkg_resources.DistributionNotFound: pip==1.5.6

[18:03:41] <dstufft> kennethreitz: do you mean broke from >=6,<6.0.6 or broke from <6.0

[18:03:50] <kennethreitz> from <6

[18:04:02] <dstufft> kennethreitz: I think older pips didn't properly overwrite the console script if one already existed

[18:04:07] <dstufft> that should be fixed in pip 6

[18:04:15] <kennethreitz> hmmm

[18:04:21] <dstufft> python -m pip install -U pip --force-reinstall will probably fix it

[18:04:40] <kennethreitz> might have to do that for heroku

[18:04:48] <kennethreitz> that did indeed fix it, excellent

[19:49:18] <aclark> kennethreitz!

[19:49:35] <aclark> dstufft: hey who added egg support to twine? Love it

[19:50:32] <dstufft> aclark: um

[19:50:40] <dstufft> I think I did that when Iw rote it originally

[19:50:44] <dstufft> maybe

[19:50:49] <dstufft> I don't really remember

[19:50:50] <aclark> dstufft: oops, I mean exe

[19:50:53] <dstufft> oh exe

[19:51:07] <dstufft> I don't recall that either ;) someone made a PR

[19:51:11] <aclark> Hah

[19:51:15] <aclark> Let's see

[19:51:29] <dstufft> I don't use exe or windows so my motivation to poke window-ey things is low

[19:52:12] <aclark> Me neither but Pillow

[19:52:21] <aclark> Hmmm I don't see "exe" in any recent commit msg

[19:53:32] <apollo13> wheels don't do it on windows?

[19:57:46] <dstufft> https://github.com/pypa/twine/pull/68

[20:28:08] <aclark> dstufft: ah, nice thanks

[20:36:30] <aclark> that's definitely over my head. I was thinking WinInst could be imported from pkgutils and used "as is" but maybe no such thing exists: https://github.com/sigmavirus24/twine/commit/dca2d31c21ef6aeaa998906745793f5aff473760#diff-797992f9d6f407a0deccad1c7875df6fR13

[21:16:59] <raydeo> hey guys I'm getting the following error despite having owner/maintainer rights to pyramid-debugtoolbar... this is a new computer so I may have something messed up but I'm able to login to pypi via "setup.py register"

[21:17:01] <raydeo> HTTPError: 403 Client Error: You are not allowed to edit 'pyramid-debugtoolbar' package information

[21:17:09] <raydeo> I'm using twine

[21:17:20] <raydeo> (1.4.0)

[21:18:11] <raydeo> pypi doesn't even show downloadable files for 2.3, but the release appears

[21:27:55] <aclark> raydeo: does setup.py upload work?

[21:28:16] <raydeo> I was hoping to avoid using it

[21:28:32] <raydeo> I've used twine with partial success in the past

[21:29:29] <raydeo> I can try it if no one from pypa can help though

[21:29:30] <aclark> raydeo: are you in a dir full o distributions running twine upload * ?

[21:29:45] <raydeo> aclark: env/bin/twine upload dist/pyramid-debugtoolbar-2.3*

[21:30:22] <raydeo> I've tried just uploading the .tar.gz as well

[21:37:49] <aclark> raydeo: how many different types o distros are in there? I'd try setup.py upload just to rule it out

[21:38:28] <aclark> I'd also try *.whl, *.egg, *.etc to see if the issue is with one of the distro types

[21:45:34] <raydeo> aclark: yeah I guess I need to point at testing.pypi if I'm gonna start screwing around

[21:45:42] <raydeo> but currently pyramid-debugtoolbar is all wonky on pypi

[21:45:57] <raydeo> I mean the previous version installs fine, but the page itself shows the 2.3 docs etc

[21:46:33] <raydeo> I just uploaded it with "setup.py upload" fine with no problems

[21:47:08] <raydeo> sdist and bdist_wheel worked, so it's just twine

[21:47:47] <raydeo> it's weird that pypi shows "py version" as 2.7 despite it being py2.py3-none-any.whl

[21:48:06] <raydeo> ok </rant> looks like a twine issue

[21:48:16] <aclark> was just about to say "twine issue" i guess

Log file Viewer

Help | Karma | Search:

#pypa logs for Monday the 5th of January, 2015