pmxbot IRC Log Viewer

[00:04:14] <lifeless> is it intended that pip is not listed in pip freeze?

[00:04:14] <lifeless> not setuptools

[00:08:28] <dstufft> lifeless: yes

[00:08:47] <lifeless> dstufft: is there a way to list it? Its annoying :)

[00:09:03] <dstufft> lifeless: pip list

[00:09:46] <lifeless> dstufft: and then sed it back to freeze format? :)

[00:09:56] <dstufft> oh you want it in the freeze format

[00:10:14] <lifeless> dstufft: well,maybe.

[00:10:17] <lifeless> dstufft: my eyes are tuned for freeze format

[00:10:35] <dstufft> I don't think there's a direct way to get it in the freeze format, most people don't generally depend on pip and pip freeze is primarily designed for > requirements.txt

[00:12:29] <lifeless> k

[04:13:10] <lifeless> dstufft: around?

[04:14:19] <dstufft> lifeless: sup?

[04:14:27] <lifeless> I have a pep-440 question for you

[04:14:31] <lifeless> I'm fixing up the pbr semver stuff

[04:14:47] <lifeless> should 1.2.3.0a4.dev12 be < or > 1.2.3.dev6

[04:15:24] <lifeless> the pep-440 prose isn't quite clear enough, as it only refers to release and pre-releases, not pre-release dev versions

[04:16:12] <lifeless> It makes sense to me that 1.2.3.dev6 would be > 1.2.3.0a4.dev12 because the pre-release component is >

[04:16:37] <lifeless> OTOH you could argue that dev versions of 1.2.3 should be < than any actual release including pre-releases

[04:17:13] <dstufft> lifeless: 1.0, 1.2.3.0a4, 1.2.3.dev6, 1.2.3, the .devN is a modifier of the rest of the version

[04:18:16] <lifeless> so is that yes or no :). where would 1.2.3.0a4.dev6 go in that list ?

[04:18:22] <dstufft> you can think of it conceptually like ("1.2.3.0a4", "dev6", "postN")

[04:18:55] <lifeless> this sentence in pep-440 is what is confusing me: Developmental releases are ordered by their numerical component, immediately before the corresponding release (and before any pre-releases with the same release segment)

[04:19:34] <lifeless> I think you're saying that 1.2.3.0a4.dev6 is < 1.2.3.dev6

[04:19:39] <lifeless> which is what I'd expect

[04:20:05] <dstufft> I think so

[04:20:07] <dstufft> let me double check

[04:20:23] <dstufft> this is a fiddly bit where there wasn't a perfect right answer

[04:20:28] <dstufft> and I think we matched what pkg_resources already did

[04:21:22] <dstufft> nope I'm wrong

[04:21:37] <dstufft> ah I know why I'm wrong too

[04:21:41] <dstufft> the .0 was throwing me off

[04:21:43] <dstufft> >>> v = ["1.0", "1.2.3.0a4", "1.2.3.dev6", "1.2.3"]

[04:21:43] <dstufft> >>> import packaging.version

[04:21:43] <dstufft> >>> sorted(v, key=packaging.version.parse)

[04:21:43] <dstufft> ['1.0', '1.2.3.dev6', '1.2.3.0a4', '1.2.3']

[04:22:16] <dstufft> it's because setuptools (and other people) viewed 1.2.3.dev6 as < 1.2.3a4, and 1.2.3 == 1.2.3.0

[04:22:48] <lifeless> is it possible to create a dev version between 1.2.3a4 and 1.2.3 ?

[04:22:58] <lifeless> If not, that seems like a rater gaping defect in the version rules.

[04:23:35] <lifeless> In fact, thats my explicit need: I need to be able to say 'this is a dev build, and its newer than that pre-release done last week, and here is a version for it'

[04:24:16] <lifeless> I have to run, picking up C now, but if you can answer here great, otherwise tonight I guess I'll start a distutils-sig thread on this

[04:25:10] <lifeless> this might be why we said we would refuse to compare pre-release and dev at all in pbr

[04:25:25] <dstufft> lifeless: I don't think there's an explicitly "post dev release", though you could do 1.2.3.0a4.postN

[04:29:31] <lifeless> dstufft: eeesh

[04:29:37] <lifeless> dstufft: for a dev build

[04:30:28] <lifeless> dstufft: It will work, but its stretching the definitions...

[04:30:28] <lifeless> dstufft: I'll start a thread after C is in bed

[14:19:50] <trishank> good morning!

[14:24:38] <sigmavirus24> Hi trishank!

[14:25:22] <trishank> hello, hello :) let me see what issue i can work on today...

[14:50:08] <trishank> iElectric: does pyramid handle redirect after login/logout?

[15:13:19] <ghickman> morning

[15:21:46] <trishank> morning, ghickman!

[15:24:54] <iElectric> trishank: you have to implement it

[15:24:57] <iElectric> morning all

[15:27:20] <trishank> iElectric: morning! yeap, looking into it now, doesn't look too hard

[15:39:44] <ghickman> how do I test a view redirects to another in pyramid land?

[15:41:23] <iElectric> ghickman: that's a warehouse faeture

[15:41:26] <iElectric> feature*

[15:42:09] <ghickman> the tests or redirecting? (sorry not following what you mean!)

[15:42:44] <iElectric> the redirect

[15:43:21] <ghickman> iElectric: with you, any suggestions on how I test it though?

[15:43:42] <iElectric> hmm

[15:44:23] <iElectric> see https://github.com/pypa/warehouse/blob/master/tests/test_redirects.py

[15:44:55] <ghickman> oh awesome, thanks =)

[15:59:49] <trishank> dstufft: can i import is_safe_url from django.utils.http to check the ?next= parameter, or is that frowned upon? i suppose we can copy the function to warehouse.utils

[16:00:33] <trishank> dstufft: the downside of copying is that we miss improvements and fixes to the function

[16:00:55] <trishank> iElectric: does pyramid have a is_safe_url function?

[16:01:26] <ryanhiebert> what are the l2-l5 columns on `Classifier`?

[16:22:14] <iElectric> hmm

[16:26:21] <iElectric> trishank: yeah, I mean we have to check that the url is relative

[16:26:50] <trishank> iElectric: no worries, i have just copied code from django in the meantime, i will let dstufft decide what to do

[16:48:31] <iElectric> dstufft: around?

[16:50:16] <trishank> iElectric: i don't get it. warehouse has a route named "accounts.profile". So why do I get a ComponentLookupError when I try request.route_path("accounts.profile")?

[16:52:20] <iElectric> you need to pass parameters

[16:52:26] <iElectric> that are needed by route

[16:52:29] <iElectric> probably username=

[16:52:40] <iElectric> grep around for examples

[16:52:44] <trishank> iElectric: well i did, but i guess it's not a named parameter? lemme see

[16:53:19] <iElectric> request.route_path('accounts.profile', username=maintainer.username)

[16:53:28] <iElectric> that's what grep finds

[16:54:21] <trishank> iElectric: yeah, my code should work...lemme dig around a bit more

[16:56:56] <Yasumoto> wickman: whoa https://rbcommons.com/s/twitter/r/2078, sweet

[16:57:25] <wickman> #winning

[17:02:10] <trishank> iElectric: looks like the tests are not somehow loading the route names into the environment

[17:02:35] <trishank> iElectric: in a test, even if i just try request.route_path("accounts.login") --- no params required --- it fails

[17:04:55] <trishank> iElectric: i'll look at test_config.py and see whether i need to load the routes config that way

[17:31:48] <trishank> iElectric: something to do with pretend, actually, trying to figure it out now

[17:34:14] <trishank> iElectric: figured it out --- the test needed a pretend stub or call recorder for request.route_path

[17:34:40] <trishank> iElectric: i wish someone had told me about this (and *why* any sort of pretending is needed at all)

[17:37:42] <trishank> okay, login test passes, i need a break, brb

[17:39:30] <iElectric> oh sorry we were at lunch

[17:44:32] <trishank> iElectric: no worries, man. how was lunch?

[17:46:02] <iElectric> average

[17:47:12] <iElectric> :D

[17:53:26] <trishank> hehe, i hope it wasn't another putin!

[19:23:54] <trishank> vlad8 and i are back from lunch

[19:53:08] <agronholm> does someone know how virtualenv installs setuptools and pip? when virtualenv creates the new environment, how is it able to import pip which hasn't been installed in the virtualenv yet?

[19:56:23] <agronholm> why am I asking? this. https://bpaste.net/show/53bffceb3d8e

[19:58:17] <ronny> agronholm: virtualenv ships the pip and setuptools wheels

[19:59:03] <agronholm> ronny: I know, but does it actually unpack them to the virtualenv before attempting to import pip?

[19:59:25] <agronholm> to me it seems like it's using pip to install pip and setuptools

[19:59:39] <agronholm> but where does the pip come from that is used to install them?

[20:00:11] <agronholm> it's using the virtualenv's interpreter to install them so the global pip is not accessible

[20:00:16] <ronny> agronholm: i dont recall

[20:00:36] <ronny> agronholm: what version of virtualenv btw?

[20:00:42] <agronholm> 12.1.1

[20:00:55] <agronholm> 12.0.7 actually

[20:02:34] <ronny> agronholm: i suspect jythonpath vs pythonpath, virtualenv adds the wheels to the pythonpath, then pip can install wheels from the host python

[20:03:03] <ronny> can jython handle wheels on pythonpath?

[20:03:20] <agronholm> what does cpython do to handle wheel import?

[20:03:31] <ronny> wheels are zip files, so its fine

[20:03:37] <agronholm> I know

[20:03:49] <agronholm> does cpython support zip import out of the box?

[20:03:52] <ronny> you jsut put them on pythonpath and it works

[20:03:57] <agronholm> ah but of course it does

[20:04:04] <agronholm> silly me

[20:04:19] <agronholm> ok, thanks -- this is a helpful clue

[20:04:49] <ronny> agronholm: try hacking the install_wheels function, replace PYTHONPATH with JYTHONPATH and try it

[20:10:57] <agronholm> ronny: you were right, that was the problem

[20:11:07] <agronholm> I'm getting another error now but that's a whole different issue

[20:15:01] <ronny> agronholm: if possible please provide a pull request that adds JYTHONPATH alongside PYTHONPATH to virtualenv

[20:15:44] <agronholm> ronny: I will

[20:16:25] <agronholm> ronny: I wonder though -- why doesn't it simply unzip them in site-packages?

[20:16:38] <agronholm> why does it need to actually run pip?

[20:16:56] <ronny> agronholm: to synthesize scripts and propperly set things in place

[20:17:18] <agronholm> oh right

[20:17:23] <ronny> agronholm: for example to deal with datafiles, metadata, nonpure things, executables and so on

[20:17:41] <agronholm> yeh

[20:46:07] <ronny> sup msabramo

[20:46:34] <msabramo> sup ronny

[20:46:59] <ronny> working on a presentation and gumy elf

[20:47:15] <msabramo> gumy elf?

[20:47:42] <ronny> eh gumby elf

[20:48:04] <msabramo> gumby elf? :)

[20:48:09] <ronny> my take at replacing setuptools fist develoepr facing, maybe later even on the sdist

[20:48:26] <msabramo> wow

[20:48:30] <ronny> currently it only features a deveop install that handles toplevels ^^

[20:49:11] <ronny> the plan is to add basic install, sdist, bdist_wheel for pure/universal wheels and ome kind of script-writing

[20:55:08] <trishank> i'm almost there with pypa/warehouse #425

[20:55:11] <trishank> someone let me know if i'm doing something wrong: https://github.com/dachshund/warehouse/tree/redirect-after-login-or-logout

[20:55:20] <trishank> #415 not #425

[21:13:19] <ronny> msabramo: what are you up to?

[21:13:41] <msabramo> adopt pytest for kallithea

[21:14:05] <ronny> msabramo: are you at their sprint?

[21:14:16] <msabramo> no I didn't attend pycon this year

[21:14:32] <ronny> i see, they are on a sprint atm, you mgiht want to join #kallithea ^^

[21:14:43] <msabramo> oh good idea, I didn't know they were sprinting

[21:32:50] <trishank> all right, i'm out for today. see you later!

[21:48:29] <dstufft> welp

[21:48:34] <dstufft> accidently slept through the entire day

[21:48:38] <dstufft> go me

[21:49:49] <iElectric> :D

[21:50:08] <iElectric> dstufft: I'm playing around with elasticsearch

[21:50:21] <iElectric> get_current_registry().settings["elasticsearch.url"]

[21:50:29] <iElectric> somehow settings is {}

[21:50:50] <iElectric> isn't that populated from dev/config.yml?

[21:51:58] <dstufft> iElectric: it's populated from there yea, in what context are you calling that

[21:52:22] <iElectric> sqlalchemy orm events

[21:52:23] <iElectric> callback

[21:52:58] <iElectric> how do I access config.yml then?

[21:54:14] <dstufft> iElectric: unless the event is firing from within a view it might not have a current registry setup

[21:54:53] <iElectric> oh I'm doing that in warehouse shell

[21:55:11] <dstufft> yea, the shell probably doesn't setup a current registry

[21:55:56] <iElectric> I thought you're using pshell underneath

[21:55:58] <iElectric> :/

[21:56:32] <dstufft> as an aside, it probably makes sense to delay the registration of the sqlalcehmy ORM event and put it inside an includeme function and pass the url from there instead of using get_current_registry

[21:56:38] <dstufft> iElectric: never heard of pshell tbh

[21:59:02] <iElectric> agreed

[21:59:09] <iElectric> I just wanted to build a prototype

[21:59:12] <iElectric> and it works :)

[21:59:29] <iElectric> dstufft: pyramid offers pshell to shell into your app

[21:59:35] <iElectric> and it sets up configurator

[21:59:38] <iElectric> and a bunch of locals

[22:00:09] <dstufft> iElectric: interesting, I just manually did it, will need to investigate pshell then

[22:00:33] <dstufft> I just did it automated calling configure() and such

[22:00:38] <dstufft> to automate*

[22:01:02] <iElectric> yeah, p namespace is quite useful

[22:01:04] <iElectric> like proutes

[22:01:44] <iElectric> dstufft: https://github.com/pypa/warehouse/pull/492 is ready to review (except for the tests)

[22:07:22] <dstufft> iElectric: will be taking a look at the pending PRs shortly

[22:08:07] <iElectric> thanks!

[22:34:31] <msabramo> should warehouse be visible at http://$boot2docker_ip/ — I get a 404

[22:35:19] <iElectric> that's what it does

[22:35:32] <iElectric> until https://github.com/pypa/warehouse/pull/492 is merged

[22:36:27] <msabramo> ah

[22:36:43] <msabramo> an index view would be useful in my opinion :_

[22:41:21] <iElectric> that's why I wrote it

[22:45:55] <msabramo> yay I'll try to try it out later

[22:45:59] <msabramo> and comment on the PR

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Tuesday the 14th of April, 2015