Log file Viewer

[06:33:56] <foxygrandpa> hi, is this the place to seek help for pip installation?

[06:35:04] <foxygrandpa> i've downloaded and installed pip, but i can't seem to run it in cmd on Windows 7

[07:39:04] <Ivo> foxygrandpa: you may not have python or python scripts folder on your path

[07:39:24] <Ivo> foxygrandpa: run C:\pythonXX\tools\scripts\winadd2path.py

[07:39:57] <Ivo> after running that a new cmd.exe should have python and pip on the path for you to just execute

[08:54:56] <foxygrandpa> Ivo: I got it, thanks

[18:48:34] <asottile> Hello, I'm trying to upload a wheel to a package on testpypi and I'm encountering the following error (using pip 1.5.6, wheel == 0.23.0, twine 1.3.0 (with a modification so I don't type passwords on commandline)): "HTTPError: 403 Client Error: You are not allowed to edit 'yelp-cheetah' package information" Is there something special I need to do to upload wheels to pypi? I had no issues uploading the sdist

[18:50:43] <asottile> my workflow is:

[18:50:43] <asottile> $ python setup.py sdist bdist_wheel

[18:50:43] <asottile> $ twine upload -r pypi-test dist/*

[18:51:08] <DanielHolth> https://pypi.python.org/pypi/yelp_cheetah ?

[18:51:26] <DanielHolth> oh, I see it

[18:51:33] <asottile> https://testpypi.python.org/pypi/yelp_cheetah

[18:52:03] <buck1> asottile: hiya

[18:52:06] <DanielHolth> twine uploaded the sdist too?

[18:52:15] <asottile> yeah twine uploaded the sdist

[18:52:56] <DanielHolth> no -u / -p ?

[18:53:22] <asottile> my modification to twine asks for it using getpass so I don't have it in my bash history

[18:53:34] <asottile> -u asottile though

[18:54:10] <asottile> my modifications can be seen here: https://github.com/asottile/twine/commits/getpass_for_not_specified

[18:54:44] <buck1> *https://github.com/dstufft/twine/pull/45/files

[19:08:14] <DanielHolth> I remember having to register a package before twine-ing it but it seems like you did that already.

[19:10:01] <asottile> yeah it registered fine, that was my first problem (before I could upload the sdist)

[22:25:34] <buck1> Submitting my-package-0.1.0-cp27-none-linux_x86_64.whl to https://testpypi.python.org/pypi

[22:25:37] <buck1> Upload failed (400): Binary wheel for an unsupported platform

[22:25:46] <buck1> is this intended? it seems like a pretty vanilla platform.

[22:43:58] <dstufft> buck1: yea it's intended

[22:44:04] <dstufft> there's a binary compatability problem on linux

[22:44:13] <dstufft> mostly that there isn't binary compatability

[22:44:43] <buck1> yea i found the ticket

[22:44:46] <dstufft> https://bitbucket.org/pypa/pypi-metadata-formats/issue/15/enhance-the-platform-tag-definition-for

[22:44:47] <dstufft> a

[22:44:48] <dstufft> ah*

[22:44:59] <buck1> dstufft: seems like you want to put unbuntu-trusty in place of linux?

[22:45:07] <buck1> etc etc

[22:45:12] <dstufft> buck1: it's one idea yea

[22:45:20] <dstufft> we're open for better suggestions :)

[22:45:35] <buck1> what will you do for the LFS distro http://www.linuxfromscratch.org/

[22:45:49] <dstufft> no idea

[22:46:36] <buck1> i think no matter how many specifiers you put on, it wont' be guaranteed to work

[22:47:08] <buck1> and also there will be some necessary specifier for .001% of packages that isn't in the spec

[22:47:55] <dstufft> nope it won't be guaranteed to work, it's not guaranteed to work on windows or os x either, however the goal is to make it work in the 99% case and then (eventually) have it fail gracefully

[22:48:01] <buck1> need to be able to add tags in setup.py, and easily fall back to building from source

[22:48:16] <buck1> sounds ok

[22:48:41] <buck1> i do think it would be good to support maintainer-defined whl tags

[22:48:53] <buck1> this build works with imagemagic 1.2 but not 1.1

[22:49:10] <buck1> both of which are available on ubuntu-trusty, for example

[22:49:28] <dstufft> how is pip going to know what those tags mean

[22:49:43] <buck1> setup.py will define a function to get the value of the tags

[22:49:51] <buck1> i guess that's chicken and egg

[22:50:08] <dstufft> there is no setup.py once a wheel has been created :)

[22:50:14] <dstufft> all pip knows is the filename

[22:50:41] <buck1> sure but the question you asked is how does it know the filename

[22:50:58] <buck1> my idea would require downloading the sdist first :(

[22:51:01] <buck1> no good

[22:51:03] <buck1> probs

[22:52:20] <dstufft> In my head the way it'll work, is that the sonames/soversions will get included inside the Wheel file, and pip will download the wheel file, and if the sonames + soversions match, use it, and if it doesn't, look for the next best match for the version it found

[22:52:50] <dstufft> so that the compatability tags are only needed to give a rough estimate of what will work to narrow down the files pip has to attempt

[22:53:13] <dstufft> but I don't know the problem domain of binary compat very well, so that's just a guess of an idea I've had based on cobbled together information

[22:53:16] <buck1> it's a shame all the available metadata is in the name =/

[22:53:44] <buck1> dstufft: at least on linux, if ldd is happy, things are happy

[22:54:13] <dstufft> yea, we might be able to just "detect" if it's OK or not

[22:54:24] <dstufft> and not need to soname/soversion

[22:54:31] <dstufft> idk

[22:54:40] <buck1> well the .so has all the linkage data in it

[22:54:53] <buck1> has the listing you're thinking of i think

[22:55:04] <dstufft> the name limitation sucks, but it also adds one really nice property, standing up your own index is super simple

[22:55:24] <dstufft> shove a bunch of tarballs in a directory, drop nginx/apache/twisted in front of it with auto index enabled and bam you have an index

[22:55:51] <buck1> adding optional metadata file won't break that

[22:55:56] <buck1> but does make it harder to maintain the pip

[22:56:07] <buck1> more states to cover

[22:56:19] <dstufft> long term we might have to move away from that, at least as an option, but right now there are bigger issues to deal with

[22:56:28] <dstufft> so it hasn't been on anyones hit list yet

[22:57:09] <buck1> imo should enable the linux whl's and improve it later

[22:57:17] <buck1> as long as there's a forward-compatibility path

[22:57:52] <buck1> i guess the fail-gracefully would block that

[23:02:56] <buck1> would it be a showstopper to make linix-wheel-making depend on lsb_release?

[23:03:04] <buck1> that's pretty miuch the tool for this.

[23:03:21] <buck1> i see LFS supports it too http://www.linuxfromscratch.org/blfs/view/svn/postlfs/lsb-release.html

[23:04:12] <buck1> these are the values you'd see if someone followed the book http://www.linuxfromscratch.org/lfs/view/stable/chapter09/theend.html

[23:04:21] <buck1> seems like it would work

[23:05:02] <buck1> ubuntu-trusty would become linux-from-scratch-buck

[23:09:13] <dstufft> buck1: I don't know what lsb_release, but if that's "the tool for this" then probably not

[23:15:09] <buck1> it's this http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html

[23:15:30] <buck1> popularity contest says 99.69% of ubuntu has it installed

[23:16:32] <buck1> 90.01% debian

[23:16:38] <buck1> http://qa.debian.org/popcon.php?package=lsb

[23:27:32] <buck1> just found this http://goo.gl/RrAZ7M