pmxbot IRC Log Viewer

[00:00:48] <dstufft> iElectric: you ran docker-compose build ?

[00:01:41] <iElectric> docker-compose up

[00:02:02] <dstufft> hrm

[00:02:11] <dstufft> that's not right..

[00:02:21] <iElectric> https://warehouse.readthedocs.org/development/getting-started/

[00:02:21] <dstufft> I wonder if a new docker image got released which broke something

[00:02:33] <dstufft> let me try to clen out my local env

[00:02:46] <iElectric> do I have to "pip install warehouse" locally?

[00:02:47] <iElectric> before I go build docker fleet

[00:02:58] <iElectric> pip install -e .

[00:03:00] <iElectric> I mean

[00:03:55] <dstufft> iElectric: nope, you shouldn't need to do that

[00:04:03] <dstufft> it should all get installed into the web container

[00:04:56] <iElectric> I didn't see any steps to install warehouse in Dockerfile

[00:05:00] <dstufft> iElectric: sec, my docker-compose is pulling things down

[00:05:32] <dstufft> iElectric: https://github.com/pypa/warehouse/blob/master/Dockerfile#L21 and https://github.com/pypa/warehouse/blob/master/dev/requirements.txt#L23-L24

[00:07:58] <iElectric> aha

[00:08:02] <iElectric> docker-compose stop

[00:08:04] <iElectric> docker-compose up

[00:08:06] <iElectric> helped

[00:08:09] <iElectric> I don't get it.

[00:08:21] <dstufft> huh

[00:08:25] <dstufft> that's strange

[00:08:33] <dstufft> this is the first time I've used docker-compose or docker really

[00:08:34] <iElectric> does it use my local code?

[00:08:47] <dstufft> yes, it will map the current directory into /app/ inside the container

[00:08:50] <iElectric> since I did do "pip install -e ." locally

[00:09:01] <iElectric> and I have virtualenv locally

[00:09:25] <iElectric> anyway

[00:09:26] <dstufft> iElectric: if you deleted .egg-info from the current directory that might have caused the issue

[00:09:33] <iElectric> I didn't

[00:09:39] <dstufft> strange

[00:12:46] <lifeless> gaarh that push to trunk broke 2618.

[00:13:00] <dstufft> lifeless: which push?

[00:13:38] <iElectric> dstufft: so how do I access warehouse?

[00:13:42] <iElectric> localhost:80/

[00:14:01] <dstufft> iElectric: are you running warehouse locally or via boot2docker or something?

[00:14:25] <iElectric> docker-compose up

[00:14:27] <iElectric> that's it

[00:15:05] <dstufft> iElectric: yea but your docker daemon is running somewhere, if you're on Linux probably running directly on your OS, if you're running on OSX probably via boot2docker

[00:15:25] <dstufft> I'm on OSX so I run it via boot2docker, so my docker IP is 192.168.59.103, so I just go to http://192.168.59.103/

[00:16:52] <iElectric> oh

[00:16:59] <iElectric> I have to access the docker ip?

[00:17:14] <dstufft> iElectric: yea, the container is running on whatever host is running docker

[00:18:45] <dstufft> gotta run to the store real quick

[00:19:22] <iElectric> dstufft: hwhat

[00:19:25] <iElectric> that's it?

[00:19:45] <dstufft> iElectric: what do you mean that's it?

[00:20:18] <iElectric> I have docker-proxy on 80 and 9000

[00:20:35] <iElectric> 80 returns 404

[00:20:44] <iElectric> 9000 returns "hwhat"

[00:20:52] <dstufft> oh

[00:20:53] <lifeless> dstufft: commit 3b4373cb1967241e2f7a7cd617f168831ea6334e

[00:20:59] <dstufft> the / is a 404

[00:21:04] <lifeless> dstufft: or perhaps commit 27c869b3622b10de63fff198a85bb99c416b1f4a

[00:21:07] <dstufft> because I didn't write a index view yet

[00:21:17] <iElectric> what can I run to verify it works?

[00:21:21] <iElectric> well

[00:21:23] <iElectric> proutes

[00:21:25] <iElectric> I guess

[00:21:33] <dstufft> iElectric: if you imported the database, /project/jasmin/ should show up

[00:22:18] <iElectric> dstufft: got it

[00:22:23] <iElectric> I can go from here

[00:22:27] <dstufft> lifeless: will take a look when i get back

[00:22:33] <dstufft> iElectric: great! sorry for the confusion

[00:22:33] <iElectric> thanks!

[00:22:42] <iElectric> np, I'll update docs

[00:22:46] <iElectric> qwcode: hey!

[00:22:48] <iElectric> (dkozar here)

[00:23:17] <qwcode> iElectric, hey : )

[00:23:42] <iElectric> I hear you help write packaging.python.org, thank you

[00:23:46] <iElectric> helped*

[00:24:04] <qwcode> iElectric, I try

[00:24:26] <iElectric> I here for PEP 426, but they told me we should build warehouse first

[00:24:29] <iElectric> so here we go

[00:24:32] <iElectric> I'm here*

[00:28:22] <qwcode> I wonder if anyone has a "todo list to achieve PEP426"... I imagine it's most clear to dstufft and ncoghlan

[00:29:11] <iElectric> if I understood there are issues somewhere on bitbucket

[00:29:23] <iElectric> couldn't get info out of nick where exactly

[00:29:32] <qwcode> I know where that is... one sec...

[00:30:02] <qwcode> although I think that moved to GH... but maybe issues left behind in BB

[00:30:15] <iElectric> yeah

[00:30:19] <iElectric> they need to be migrated

[00:31:49] <qwcode> old location: https://bitbucket.org/pypa/pypi-metadata-formats new: https://github.com/pypa/interoperability-peps

[00:32:14] <iElectric> awesome!

[00:32:28] <qwcode> issues in BB https://bitbucket.org/pypa/pypi-metadata-formats/issues?status=new&status=open&component=Metadata%202.x

[00:32:34] <iElectric> so how are you solving wheel tagging?

[00:32:45] <iElectric> the only way I see is to have arbitrary tags

[00:33:00] <iElectric> and then distros would invent their own versioning for glibc lifecycle

[00:33:25] <iElectric> so "-ubuntu-14.04", etc

[00:33:55] <iElectric> if you're going to promise people that pip will handle what wheel to use automatically

[00:34:01] <iElectric> that's going to fail miserably

[00:34:11] <iElectric> even if it works 80% of the time..

[00:34:29] <iElectric> just my 2c

[00:35:55] <iElectric> ohhh you're planing to use SPDX license tags

[00:35:57] <iElectric> awesome

[00:35:59] <iElectric> o/

[00:37:41] <qwcode> I think it should have support for arbitrary tags, but also detection of os-release if desired

[00:37:59] <iElectric> that will never work 100%

[00:38:06] <iElectric> so it's a promise you can't really make

[00:38:44] <qwcode> it can be an option to use it.

[00:39:51] <iElectric> sure :)

[00:40:11] <qwcode> https://mail.python.org/pipermail/distutils-sig/2014-November/025297.html

[00:40:41] <iElectric> yeah that won't work

[00:40:50] <iElectric> at least 10% of the time

[00:41:00] <qwcode> why 10%?

[00:41:49] <iElectric> because os-release doesn't guarante ABI compatibility

[00:43:02] <iElectric> like you'll miserably fail on all rolling distros

[00:43:05] <iElectric> for start

[00:43:42] <qwcode> ignoring rolling distros... doesn't os-release value generally ensure ABI stability...?

[00:44:15] <iElectric> in LSB theory

[00:44:40] <iElectric> but not really

[00:46:20] <qwcode> what can I actually query on a redhat/centos machine that identifies an ABI consistent state

[00:47:55] <iElectric> pretty much nothing

[00:48:17] <iElectric> at the end you have to decide where to draw the line

[00:48:20] <qwcode> I'm confused, you're talking about "-ubuntu-14.04" above

[00:48:45] <iElectric> so I meant that we should promise that it works transparently

[00:49:40] <qwcode> transparently?

[00:49:58] <iElectric> so instead of pip figuring out whell tag

[00:50:11] <iElectric> user would set global setup.cfg or something

[00:50:20] <iElectric> or say "... whell --tag ubuntu-14.04

[00:50:25] <iElectric> wheel*

[00:50:48] <iElectric> it's still going to be a mess

[00:50:51] <iElectric> :)

[00:51:07] <qwcode> but to be clear, you're saying "ubuntu-14.04", as a tag, is just not good enough..

[00:51:08] <iElectric> python packaging can't solve ABI, that should really be out of scope

[00:51:30] <iElectric> qwcode: yeah then ubuntu folks could say to use ubuntu-14.04-2

[00:51:32] <iElectric> etc

[00:54:43] <dstufft> iElectric: honestly, not working 10% of the time is fine

[00:54:54] <dstufft> well

[00:54:55] <dstufft> to be clear

[00:55:05] <dstufft> as long as it's determinstic and the package author can do something about it

[00:56:34] <qwcode> do what?, --ignore-platform-wheels

[00:57:11] <iElectric> more probably, build from source

[00:57:40] <iElectric> that's why I want to get pep 426 done, then we can package whole pypi for nix

[00:57:47] <iElectric> as haskell and R guys did it

[00:59:08] <dstufft> the other thing we can do is bake in an ABI as part of the wheel metadata, and only use the tag as a guesstimate about what file _might_ be sutiable, download, verify the ABI info, then if it doens't match, download any other options we have for that version

[00:59:36] <qwcode> iElectric, so, you'd be building wheels for nix, for every rev of nix? what kind of tag would you be using

[00:59:44] <iElectric> no need to use tags

[01:00:01] <iElectric> it's turtles all the way down

[01:00:10] <iElectric> http://static.domenkozar.com/slides/pycon-us-2015/#/5

[01:01:18] <iElectric> dstufft: sure

[01:01:36] <qwcode> "bake in an ABI" specified how?

[01:01:55] <iElectric> dstufft: one question, I saw wheels write what python versions does a wheel support

[01:02:16] <iElectric> for all python versions

[01:02:30] <iElectric> how does it figure out what versions it supports

[01:03:33] <iElectric> or am I imaginingg things?

[01:04:27] <qwcode> iElectric, https://github.com/pypa/pip/blob/develop/pip/pep425tags.py#L55

[01:04:37] <qwcode> "Support all previous minor Python versions"

[01:05:21] <iElectric> tnx

[01:05:40] <qwcode> that module actually came from wheel... it's duplicated right now

[01:10:56] <qwcode> iElectric, how do binary wheels matter for nix?

[01:11:11] <iElectric> they don't

[01:11:17] <iElectric> I mean I have a branch to use them

[01:11:18] <qwcode> ok, got it : )

[01:11:21] <iElectric> but there is really no gain

[01:11:29] <iElectric> instead of using wheels as they're specified

[01:11:40] <iElectric> it's just an internal specification

[01:11:45] <iElectric> s/specification/format/

[01:11:57] <iElectric> sorry I'm still jetlagged

[01:12:25] <qwcode> I guess it's not "allowed" to install using pip on nix. it would break the whole model

[01:12:32] <iElectric> yeah

[01:12:53] <iElectric> so if python packages used static metadata

[01:13:05] <iElectric> you could query warehouse to download that for all of packages

[01:13:16] <iElectric> then generate nix expressions automatically

[01:13:22] <iElectric> and have python-overrides.nix

[01:13:46] <iElectric> pillow = super.pillow.override { buildInputs = [ pkgs.libjpeg ..] };

[01:13:53] <iElectric> that way you can package while pypi :)

[01:16:49] <iElectric> alright gonna call it a day, thanks for help

[01:17:26] <qwcode> later

[02:24:07] <lifeless> dstufft: fixed, I think

[02:24:32] <lifeless> ah, but another push that conflicts.

[02:25:05] <lifeless> tere

[03:57:48] <bowlofeggs> i won't be around for monday-tuesday sprints, but i'll be watching this channel when i get back on wednesday. happy hacking!

[08:46:53] <lifeless> ok https://github.com/pypa/pip/pull/2618 is green again.

[08:46:56] <lifeless> please be to merging it :)

[13:53:13] <wickman> yay pycon too many global connections.

[13:53:30] <dstufft> nobody got an exception from freenode? :/

[13:55:53] <wickman> last year it happened somewhere later in the day on monday

[14:19:57] <trishank> hello, everyone!

[14:20:08] <dstufft> trishank: heya!

[14:20:16] <dstufft> lifeless: I merged 2618

[14:43:11] <trishank> i'm getting an error trying to docker-compose up

[14:43:18] <trishank> does anyone know what this means?

[14:43:21] <trishank> camo_1 | SSL-Proxy running on 9000 with pid:1 version:2.2.0.

[14:43:21] <trishank> web_1 | Traceback (most recent call last):

[14:43:21] <trishank> web_1 | File "/usr/local/bin/warehouse", line 5, in <module>

[14:43:21] <trishank> web_1 | from pkg_resources import load_entry_point

[14:43:22] <trishank> web_1 | File "/usr/local/lib/python3.4/site-packages/pkg_resources/__init__.py", line 3018, in <module>

[14:43:24] <trishank> web_1 | working_set = WorkingSet._build_master()

[14:43:27] <trishank> web_1 | File "/usr/local/lib/python3.4/site-packages/pkg_resources/__init__.py", line 612, in _build_master

[14:43:29] <trishank> web_1 | ws.require(__requires__)

[14:43:31] <trishank> web_1 | File "/usr/local/lib/python3.4/site-packages/pkg_resources/__init__.py", line 918, in require

[14:43:33] <trishank> web_1 | needed = self.resolve(parse_requirements(requirements))

[14:43:36] <trishank> web_1 | File "/usr/local/lib/python3.4/site-packages/pkg_resources/__init__.py", line 805, in resolve

[14:43:38] <trishank> web_1 | raise DistributionNotFound(req)

[14:43:40] <trishank> web_1 | pkg_resources.DistributionNotFound: warehouse==15.0.dev0

[14:43:41] <trishank> warehouse_web_1 exited with code 1

[14:43:44] <trishank> Gracefully stopping... (press Ctrl+C again to force)

[14:43:45] <trishank> Stopping warehouse_camo_1...

[14:43:48] <trishank> Stopping warehouse_redis_1...

[14:43:52] <trishank> Stopping warehouse_db_1...

[14:46:40] <dstufft> trishank: iElectric had this problem yesterday too :( Do you have a .egg-info in your current working directory?

[14:46:59] <r1chardj0n3s> ohai dstufft and all

[14:47:49] <iElectric> hi all!

[14:47:54] <trishank> dstufft: sadly, no

[14:47:57] <iElectric> trishank: try docker-compose stop

[14:47:59] <iElectric> and up again

[14:48:06] <trishank> iElectric, ok lemme try

[14:49:04] <trishank> iElectric, did not work, same error :(

[14:49:35] <trishank> is it trying to fetch warehouse==15.0.dev0 from pypi?

[14:49:42] <dstufft> trishank: try to run ``python setup.py egg_info`` in your current dir

[14:49:54] <iElectric> it's probably pip failing to install everything

[14:51:04] <trishank> dstufft, iElectric: that seems to have worked

[14:55:28] <aodag> trishank: try docker-compose build

[14:55:45] <aodag> and docker-compose up

[14:57:24] <iElectric> r1chardj0n3s: are you also sprinting on warehouse?

[14:57:28] <trishank> aodag: thanks, i did these to get everything working...

[14:57:30] <r1chardj0n3s> iElectric: yes

[14:57:47] <r1chardj0n3s> (well, not quite yet, I slept in)

[14:58:06] <trishank> 1. python setup.py egg_info

[14:58:25] <trishank> 2. migrate the DB: https://warehouse.readthedocs.org/development/getting-started/

[14:58:32] <trishank> 3. docker-compose up

[14:58:43] <trishank> 4. browser http://localhost/project/jasmin/

[14:58:49] <iElectric> cool I'll fix the docs

[14:58:55] <iElectric> and create a simple index for now

[14:59:18] <r1chardj0n3s> can anyone tell me what the story is with wheels on OS X and Frameworks?

[14:59:18] <trishank> iElectric: thanks! a global simple index, as in http://localhost/simple/?

[14:59:48] <iElectric> r1chardj0n3s: I'm in 514c with rest of pyramid folks but I'm ready to move elsewhere

[15:00:04] <r1chardj0n3s> iElectric: we are also in 514c

[15:00:09] <r1chardj0n3s> table "anonymous"

[15:00:18] <dstufft> I have a fix to the missing egg-info thing in just a moment

[15:00:24] <dstufft> well a work around

[15:00:44] <iElectric> just a simple view for /

[15:02:49] <iElectric> k

[15:03:06] <ryanhiebert> Letting everyone know I'm here (at the warehouse table). I'm brand new to all of this, so I'm figuring it all out.

[15:05:38] <dstufft> ryanhiebert: heya

[15:09:02] <dstufft> https://github.com/pypa/warehouse/pull/477 this should fix the missing warehouse.egg-info problem

[15:11:51] <r1chardj0n3s> seriously hating computers right now http://paste.openstack.org/raw/203599/

[15:12:08] <r1chardj0n3s> (or possibly just homebrew)

[15:12:36] <dstufft> r1chardj0n3s: you might have installed it with the .app thing that docker has?

[15:12:58] <r1chardj0n3s> I'm pretty sure it was homebrew, but it was over a year ago so yeah, I probably did :(

[15:18:02] <ghickman> dstufft: are there any issues that are low hanging fruit I should focus on (at the sprints) for warehouse?

[15:18:54] <dstufft> https://github.com/pypa/warehouse/milestones/Become%20PyPI has everything that I thought was important to actually launch warehouse in place of PyPI, let me see if I can tag any of these as easy

[15:19:53] <ghickman> cool, thank you

[15:21:15] <trishank> i'm working on #438

[15:23:24] <dstufft> just tagged a few that are pretty shallow, there are other things which are easier than others, but aren't as shallow

[15:23:30] <dstufft> maybe a medium tag would be decent for those

[15:26:09] <dstufft> there tagged some stuff as medium too

[15:29:15] <trishank> iElectric: so in warehouse/routes.py, there is config.add_route("legacy.api.simple.index", "/simple/"). Does this mean that the simple_index function in warehouse/legacy/api/simple.py is called to pass objects to the "legacy/api/simple/index.html" renderer?

[15:29:53] <ghickman> cheers dstufft

[15:30:28] <iElectric> trishank: pyramid has two components to routing

[15:30:31] <iElectric> url -> route name

[15:30:34] <iElectric> route name -> view name

[15:30:48] <iElectric> and view name is mapped to a function

[15:30:55] <iElectric> (using @view_config decorator)

[15:31:04] <dstufft> trishank: it register a route with a specific name, later on a view says that it works for a particular route name

[15:31:31] <dstufft> trishank: https://github.com/pypa/warehouse/blob/master/warehouse/legacy/api/simple.py#L23

[15:33:38] <trishank> iElectric, dstufft: aha, i see. so is it a convention to implement "simple_index" in legacy/api/simple.py if i define a route with the name "legacy.api.simple.index"?

[15:34:23] <dstufft> trishank: for warehouse yea, I try to make the route name give some clue as to where you can find the view that implements it

[15:34:45] <iElectric> I think r1chardj0n3s doesn't like docker

[15:35:13] <dstufft> lol

[15:35:30] <dstufft> r1chardj0n3s: you don't have to run it in docker if you don't want fwiw, you'll just need to start the services up yourself

[15:35:35] <trishank> dstufft: cool, thanks

[15:35:53] <dstufft> postgresql, warehouse, redis, and camo

[15:36:37] <dstufft> docker was (supposed) to just be there so epeople didn't hav eot learn how to install a bunch of other components, jsut docker and then go

[15:36:57] <iElectric> dstufft: too late ^^

[15:37:09] <iElectric> it would be so much easier to do

[15:37:16] <iElectric> nix-shell -p postgresql94 redis libxml2

[15:37:25] <iElectric> and have supervisord or something

[15:37:32] <iElectric> and that works on darwin

[15:37:34] <iElectric> just sayin..

[15:39:18] <dstufft> iElectric: I suspect you may be biased in that ;) (Not that you're wrong, no idea if you are. I've never actually used nix)

[15:40:24] <iElectric> ah I am

[15:40:24] <iElectric> :)

[15:40:46] <iElectric> I just don't but the whole "let's use runtime isolution to solve packaging/configuration problem"

[15:40:50] <ghickman> I'll pick up #404

[15:41:04] <iElectric> anyway, I'm working on a simple / view

[15:41:23] <dstufft> ghickman: toss a comment on the issue please

[15:41:29] <dstufft> probably will make it easier to coordinate

[15:41:31] <ghickman> sure thing

[15:42:35] <dstufft> ghickman: for that one, you can see an example of the warning that an older code base had imlpemented on https://warehouse.python.org/project/Django/1.8a1/

[15:42:45] <dstufft> doesn't have to look just like that or anything

[15:42:48] <dstufft> jsut an example

[15:42:57] <ghickman> ok cool, thanks

[15:43:21] <ghickman> I take it warehouse.python.org isn't the current code base then?

[15:46:27] <dstufft> ghickman: Nah, it's from the "werkzeug" branch

[15:46:36] <dstufft> folks were concerned about my custom wierdo framework :)

[15:46:40] <dstufft> so I rewrote it in Pyramid

[15:46:42] <ghickman> ok good to know

[15:46:45] <ghickman> haha ok

[15:47:16] <dstufft> I didn't get around to swapping around th edeployment stuff

[15:50:14] <qwcode> dstufft, I'm not reallly following warehouse.... but "rewrote it in Pyramid", really?

[15:50:23] <dstufft> qwcode: yea

[15:50:30] <qwcode> interesting... : )

[15:50:39] <dstufft> bad interesting or good interesting?

[15:51:25] <trishank> out of curiosity, why not Django?

[15:52:57] <qwcode> dstufft, I'm a bit sentimentally biased towards pylons projects historically, just because I used TG2 for a few years, but just saying "interesting", because It sounds like it's been quite a journey to figure out what's best

[15:53:56] <qwcode> all of my examples in pip issues use "deform" and "peppercorn" which are pylons projects

[15:54:39] <dstufft> trishank: I despise global state and Django has some ;) Also because the Django ORM requires more work to fit the current PyPI schema, and if you're throwing away the Django ORM you're throwing away most of what makes django interesting (the massive library of projects that you can use), plus I want to do some "weird" things that Pyramid made easier (like disallow access to the session unless you decorate the view)

[15:55:23] <trishank> dstufft: makes sense, easier to customize a microframework

[15:56:03] <dstufft> qwcode: heh, I came out of the django world :) but yea it's been a bit of a journey, at this point I have half way implemented Warehouse in Django, Flask, Werkzeug, and now Pyramid :D

[15:56:33] <dstufft> I'm pretty happy with Pyramid though

[15:56:35] <qwcode> wow

[15:56:47] <dstufft> (I'm also pretty picky

[15:58:43] <iElectric> pyramid is awesome :)

[16:01:10] <dstufft> woops

[16:01:15] <dstufft> work meeting I forgot about

[16:12:55] <iElectric> qwcode: pyramid is very different to TG2

[16:13:19] <iElectric> think of pylons project as apache project

[16:21:40] <qwcode> iElectric, I know

[16:22:17] <iElectric> it's written by different people and under difference codebase under the same project name

[16:23:45] <qwcode> roger, there was talk at some point of TG building on pyramid... but that may have died out...

[16:24:18] <iElectric> yeah

[16:24:54] <qwcode> MarkR and ChrisD had a little video thing they posted about the merger years ago that I watched

[16:25:23] <qwcode> ChrisM I mean

[16:27:41] <iElectric> I like because it has awesome docs

[16:27:47] <iElectric> and all code is written with unittesting in mind

[16:27:57] <iElectric> def view(request): return {}

[16:28:20] <qwcode> iElectric, and you're a committer too. that helps : )

[16:30:43] <iElectric> just a few minor improvements

[16:31:25] <qwcode> iElectric, ok last off-topic post. the video I watched way back in 2008 where I considered pylons/TG2 over Django https://www.youtube.com/watch?v=fipFKyW2FA4

[16:44:06] <trishank> brb, meeting

[16:51:42] <iElectric> qwcode: hehe, never saw that one

[17:14:28] <iElectric> dstufft: where do you want me to place "/" view?

[17:14:37] <iElectric> I put it into legacy/api/index.py

[17:14:38] <iElectric> for now

[17:14:54] <dstufft> iElectric: I dunno, I guess warehouse/views.py is fine

[17:17:10] <iElectric> k

[17:33:52] <iElectric> dstufft: do I see correctly we don't use bootstrap?

[17:38:23] <dstufft> iElectric: not currently. I'm not opposed to using it. I was trying somehting else but I don't really care what we use. WhatI'd really like is to convince a designer to help out and let them pick :D

[17:40:40] <iElectric> :D

[17:40:43] <iElectric> agreed

[17:40:50] <iElectric> hmm

[17:40:55] <iElectric> not sure where to start >.<

[17:43:59] <ghickman> dstufft: I saw tox is calling pytest with `python -m coverage run -m pytest …` - wondering if there's was a decision behind that versus pytest & pytest-cov?

[17:52:27] <trishank> dstufft: back from meeting, will address your comments on #438

[17:55:37] <dstufft> ghickman: habit, pytest-cov doesn't work in all situations (particularly more advanced ones)

[17:55:44] <dstufft> it'd probably work fine for warehouse

[17:56:03] <ghickman> oh ok cool, was purely curious since I knew the plugin existed

[17:56:23] <ghickman> I'm not bothered about leaving it like that - it's pretty obvious what's going on from tox.ini stuff

[18:02:58] <trishank> dumb question. how do i run tox within the docker env?

[18:08:29] <trishank> let me rephrase. i can't seem to just run tox in the tests/ folder without getting errors, but the doc says otherwise. does anyone know why?

[18:22:36] <dstufft> trishank: what erros do you get?

[18:23:27] <trishank> firstly, without sudo, permission denied: py.error.EACCES: [Permission denied]: open('/path/to/warehouse/.tox/log/tox-1.log', 'w')

[18:24:04] <dstufft> sudo? You shouldn't need to use sudo for anything

[18:24:17] <dstufft> try to delete the .tox directory

[18:28:34] <trishank> ok, lemme try

[18:29:38] <trishank> now i get: Error: pg_config executable not found.

[18:30:13] <trishank> it's not able to find postgres without the docker environment, i guess?

[18:30:39] <trishank> i've not used docker before, so sorry if i'm doing something obviously silly

[18:35:19] <dstufft> trishank: oh, the test suite probably depends on having PG installed in the host OS, one sec

[18:39:16] <dstufft> trishank: can you past the whole traceback?

[18:39:47] <ryanhiebert> I gave up on trying to use docker, and I'm working on just getting stuff up with local postgres and redis.

[18:40:37] <dstufft> ryanhiebert: :/

[18:40:44] <dstufft> so much for trying to use docker to make things easier

[18:42:56] <ryanhiebert> I think it was just stupid stuff with my docker. It would only tell me that the certificate wasn't valid.

[18:43:12] <ryanhiebert> (boot2docker)

[18:48:34] <trishank> dstufft: http://pastebin.com/STEE7f4q

[18:49:00] <dstufft> trishank: oh, of coruse

[18:49:12] <dstufft> you can't install psycopg2 without the devleopment headers for pgclient

[18:49:26] <dstufft> trishank: what OS are you on?

[18:49:48] <trishank> dstufft: ubuntu 14.10

[18:50:15] <dstufft> trishank: sudo apt-get install libpq-dev python-dev

[18:50:23] <dstufft> that should get you what you need to install psycopg2

[18:52:22] <trishank> dstufft: seems to work, but a different error now: http://pastebin.com/XEKjAtys

[18:53:53] <dstufft> trishank: you probably need tod elete .tox again, you probably got a broken environment when psycopg2 wasn't able to be installed

[18:53:56] <dstufft> delete*

[18:54:46] <trishank> dstufft: retrying

[18:57:41] <trishank> dstufft: i get this now: http://pastebin.com/RG56r5qk

[18:58:17] <dstufft> trishank: oh, you need sudo apt-get install libffi-dev too

[18:58:23] <dstufft> and then delete .tox and try again

[18:58:42] <trishank> dstufft: ok let me retry (i'll submit a PR that documents all this)

[19:04:55] <trishank> brb, meeting

[19:10:49] <trishank> ok so it's apt-get install libffi-dev libpq-dev python3-dev

[19:11:09] <trishank> (not python-dev because that's for python 2 and bcrypt would keep failing to compile)

[19:11:22] <trishank> however, different error now! hold on for pastebin...

[19:14:30] <trishank> idk why the tox is taking so long, but it seems to do with postgres not finding a db with that name or credentials for running tests

[19:15:12] <trishank> http://pastebin.com/fKzww3XZ

[19:16:15] <trishank> can i run tox within the docker env to avoid all these issues?

[19:18:44] <dstufft> trishank: um, you might be able to run tox within the docker env, if you do ``docker-compose run web bash``

[19:18:56] <dstufft> that shoudl spawn a bash shell running inside of the docker env

[19:19:12] <dstufft> you'll probably need to do pip install tox once inside there to get tox installed

[19:44:16] <iElectric> yay we have internet again

[19:44:43] <vlad8> /whois dstufft

[19:45:27] <dstufft> vlad8: hey

[19:45:46] <vlad8> hello :P

[19:46:36] <lifeless> morning

[19:46:38] <lifeless> dstufft: thanks!

[19:49:31] <dstufft> lifeless: no problem, I opened up a few issues to track some pending work/questions, but I figured the structure and such was solid and instead of needing to keep rebasing it'd make sense to tackle those things in additional changes

[20:11:33] <trishank> does anyone have tox working on warehouse? if so, please tell me how you got there

[20:14:36] <trishank> i'm at the stage where the tests can't find some postgresql bin: http://pastebin.com/fKzww3XZ

[20:14:42] <ghickman> trishank: I have it working outside of docker

[20:15:03] <ghickman> trishank: your paste has been removed?

[20:15:12] <trishank> ghickman: sorry, let me redo

[20:15:54] <trishank> ghickman: http://pastebin.com/8Wy4Atp8

[20:16:19] <trishank> the process call returns 127, which makes sense, because that 9.4 binary is not there on my system

[20:17:24] <ghickman> can you install postgres 9.4?

[20:17:48] <trishank> ghickman: let me try that, i figured only the postgres lib was needed, but apparently not

[20:18:20] <ghickman> yea, IIRC various things use pg_ctl and look for other things you get with the full install

[20:25:06] <trishank> ghickman: installing postgres fixed that problem, and now there is something else.... some operationalerror because some extension control file is missing

[20:25:26] <trishank> ghickman: i'm going to figure all this out and document this so that no one else has to go through this again

[20:25:39] <ghickman> trishank: that would be good, thanks

[20:28:40] <dstufft> trishank: you probably need to install postgresql-contrib too on ubuntu

[20:28:52] <dstufft> I think ubuntu splits up the contrib away from postgresql

[20:28:56] <trishank> dstufft: yeah, just found that on google

[20:29:13] <trishank> dstufft: i think it's best to run this on docker, though i'm trying the manual way now

[20:29:23] <dstufft> probably the tests should be smart effect to figure out if postgresql isn't installed and just skip the tests that rely on them

[20:29:28] <dstufft> smart enough*

[20:30:09] <trishank> now i'm here! http://pastebin.com/y1AaL0pB

[20:30:11] <trishank> almost there

[20:32:18] <trishank> i think it all works now

[20:32:26] <dstufft> trishank: the py34 failure looks right, there's a missing line that isn't being covered. the docs failure is weird, did you run tox with sudo?

[20:32:32] <trishank> the tests fail because my new code gives less than 100% code coverage

[20:32:41] <dstufft> if you run tox with sudo it'll create some files with the root user instea dof your user

[20:32:42] <trishank> dstufft: yeah, the doc failure is weird

[20:32:51] <trishank> dstufft: let me nuke tox from orbit and retry

[20:33:06] <trishank> for everyone else until i submit a PR: apt-get install libffi-dev libpq-dev python3-dev postgresql postgresql-contrib

[20:34:17] <iElectric> nix-shell -p libffi postgresql

[20:34:19] <iElectric> :)

[20:34:47] <trishank> iElectric: clever fellow ;) you should add those instructions later

[20:39:07] <trishank> dstufft: i think it's a leftover from my previous use of tox with sudo; left a _build under /docs/ with root permissions; deleting that and retying

[20:39:23] <dstufft> trishank: makes sense

[20:44:47] <trishank> dstufft: docs are generated now

[20:51:21] <iElectric> hmm

[20:51:21] <iElectric> I don't see all this refill images

[20:51:21] <iElectric> https://raw.githubusercontent.com/thoughtbot/refills/master/source/images/placeholder_logo_1.png

[20:51:21] <iElectric> even browser returns nothing

[20:52:04] <dstufft> iElectric: I probably forgot to rehost it and the CSP rules prevent images from other domains

[20:54:48] <Yasumoto> wickman: some value from my spelunking https://github.com/pantsbuild/pex/pull/67

[20:57:17] <iElectric> yeah disabling CSP works

[20:58:31] <iElectric> I'll try to fix it

[21:05:35] <iElectric> dstufft: noob question, are all refill scss files in our repo?

[21:06:49] <dstufft> iElectric: refills are not, because refills are more like "snippets" that you're expected to copy/paste and adjust. Bourbon is isntalled via npm and bitters is commited to the repo

[21:17:01] <ryanhiebert> would there be any interest in getting this running on Heroku? It would then be possible to have PRs automatically create heroku apps that would be reviewable. Overkill for little changes, but I expect a huge help for reviewing larger features.

[21:18:21] <lifeless> dstufft: ok so

[21:18:27] <lifeless> dstufft: I've promised to do a pbr patch that is breaking peoples brains

[21:18:28] <lifeless> dstufft: (semver update)

[21:18:43] <lifeless> dstufft: after that I can swing back and look at the incremental issues, if noone at the sprints has done them

[21:19:14] <dstufft> ryanhiebert: that's an interesting idea, if it's not super hard it might be a neat idea. If it's hard or will require babysitting it might not be worth it.

[21:19:16] <dstufft> lifeless: works for me

[21:20:02] <lifeless> dstufft: (encourage folk at the sprints to do them :))

[21:20:25] <dstufft> ryanhiebert: mostly because I think most changes are easy enough to test locally if there's a question about how it'll function reality

[21:20:33] <lifeless> dstufft: should we add cover-diff to pip travis? seems like a good incremental way to build up the test suite

[21:20:44] <dstufft> lifeless: it's already there, we just don't gate on it

[21:20:52] <dstufft> well it's there for the unit tests

[21:20:55] <dstufft> not for the functional tests

[21:21:10] <dstufft> I haven't gotten around to figuring out how to get coverage to work inside of a subprocess

[21:21:45] <ryanhiebert> ok. won't waste my time going that way... I'm chasing down an understanding of #407 to see if I can take it.

[21:21:56] <lifeless> dstufft: subprocess - oh thats easy

[21:22:24] <lifeless> dstufft: a) you use coverage as $PYTHON, there's examples in the pbr codebase where it has a testr wrapper

[21:22:43] <lifeless> dstufft: b) you run coverage in parallel mode, and then merge the coverage data once all the processes have completed

[21:23:52] <dstufft> gotta go pick up dinner

[21:23:55] <dstufft> bbs

[21:50:50] <trishank> okay everyone, i'm out for today

[21:51:00] <trishank> thanks for all your help, and see you later!

[21:51:06] <iElectric> o/

[22:46:45] <iElectric> dstufft: quick preview of "/" view: http://i.imgur.com/YcLKw7X.png

[22:46:55] <iElectric> need to center the stats

[22:47:03] <iElectric> and put projects in a table..

[22:48:19] <dstufft> iElectric: awesome! I haven't been too focused on making things look amazing, just semi functional so don't feel a need to go crazy on the looks deptartment (though making it look good doesn't hurt ;))

[22:50:07] <iElectric> yeah I'll stop there

[22:50:07] <iElectric> I went from "this css framework sucks balls" to "this beer is helping.."

[22:51:04] <dstufft> iElectric: I was trying it out, I think bourbon makes a lot more sense if you actually know how to CSS well and don't just fuck about until it looks ok

[22:54:30] <iElectric> yeah

[22:54:42] <iElectric> which is pretty much the oppoosite what we do

[22:54:44] <iElectric> hehe

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Monday the 13th of April, 2015