Log file Viewer
#pypa logs for Sunday the 20th of April, 2014
[17:03:42] <dstufft> So, depending on something is a no-go in pip. We have one sort of dependency right now (setuptools) and having that has caused massive headaches
[17:04:06] <dstufft> Even if debian and such will patch it out, there's still OSX and Windows, and also virtualenvs and the like
[17:04:57] <zyga> dstufft: but for xdg it might (*might*) make sense to reconsider how your downstreams will consume it (on foss platforms), debian will most certainly patch the copy of python-xdg (if you choose to use it) with a plain dependency, for windows and osx that is not a dependency so I'd say it's a bit special
[17:06:16] <zyga> dstufft: and Debian folks wanted to stay in sync with fedora no to deviate too much without reasons (though you probably recall barry's comments on boostrapping issues)
[17:06:31] <dstufft> It's still up for debate, I don't think the rewheel thing is going to be a generally good idea unless rewheel also rebundled
[17:07:32] <dstufft> But we can't conditionally add stuff to pip's source, so even if debian and them rip it out, and it's only useful on Linux, we have to bundle it in a way that it'll always be available
[17:07:59] <dstufft> and I have no idea what the legal rammifications are if we add a LGPL library directly to our source in pip._vendor.xdg
[17:08:29] <zyga> dstufft: but just depend on it (crazy a bit) and work with downstreams to package it correctly?
[17:08:54] <zyga> dstufft: there's the use case of pip-from-source but I don't know how important that is on linux really
[17:08:58] <dstufft> A lot of people don't install pip from the OS packages and they use get-pip.py too
[17:09:44] <dstufft> right now if I think only Ubuntu 14.04 has a copy of pip that isn't grossly insecure
[17:09:45] <zyga> dstufft: I'd love to know the rationale for doing that (though this is somewhat tangent to the problem you are trying to solve)
[17:10:05] <Alex_Gaynor> it's not like there's a package manager for OS X or windows, and debian is almost always out of date with the latest pip
[17:10:51] <zyga> Alex_Gaynor: I didn't mean the alternative to not running get-pip.py is running old pip, there are backports and other "proper" ways to use latest software on production releases
[17:11:23] <zyga> Alex_Gaynor: get-pip.py (perhaps it is far better than average) is the windows style of 'download exe and hope for the best' that people really need to be steered away from
[17:12:07] <dstufft> I tried to backport TLS verification to 1.0 and 1.1 which is what the LTS versions of Ubuntu and the latest stable of Debian had
[17:12:59] <dstufft> I mean generally I try to point people towards installing from Os packages where it makes sense, but I doubt people are going to stop doing that anytime soon :]
[17:13:21] <dstufft> and it's better to not be broken than to be broken and tell someone they did something wrong
[17:13:47] <zyga> right, it's a process, we just need to make (from both sides of upstream/distro) to make it easier and better to do the right thing
[17:14:52] <dstufft> We actually try real hard to make it easy for Downstream to un-vendor stuff (although I wish they wouldn't) :]
[17:15:23] <dstufft> We only will vendor released versions, and we have a policy against patches except so as to make vendoring work (e.g. we pretty much can only change import statements to import other vendored stuff)
[17:15:51] <zyga> dstufft: there's a lot of discussion around vendoring, I think it's not such black-and-white as many people make it but there are good arguments on both sides, still for some parts of the OS un-vendoring is essential
[17:17:00] <dstufft> pip vendors because it depends on these things, and if they aren't there or are the wrong version you lose the ability to use pip. If it was something other than pip you could just use pip to fix it, but if you break pip you're stuck with manually installing stuff
[17:17:46] <dstufft> This is lessened on OSs with a package manager because you can fix it with the OS package manager generally (although not always), but that doesn't work in virtualenvs
[17:19:38] <zyga> I think one thing that pip does that makes not vendoring stuff difficult is the desire to support old stuff (that distributions would like to forget and move on), this is what makes pip popular and useful but it's carries a price
[17:20:06] <dstufft> Luckily XDG is as easy as os.path.expanduser(os.path.join(os.environ.get("XDG_USER_CONFIG", "~/.config")), "pip", "pip.conf")
[17:20:55] <dstufft> figuring ou what goes where on OSX and Windows is the annoying part of this whole thing :[
[17:21:42] <dstufft> zyga: Yup, but most stuff that uses the built in OSX directories has a preference pane, everything else just uses ~/.something
[17:22:01] <zyga> dstufft: so behind the preference pane there are files, those files have good placement
[17:22:03] <dstufft> There's ~/Library/Preferences, but it only has plists in it, so no idea if it's OK to put an ini style file in there or not
[17:22:19] <dstufft> there's also ~/Library/Application Support/ which some apps use for configuration
[17:22:27] <zyga> dstufft: I guess not using ~/.crap is infinitely better than using ~/Library poorly (if that can be done poorly at all)
[17:25:42] <dstufft> I have twine -> https://warehouse.python.org/project/twine/ which supports ~/.pypirc bu also passing things in on the CLI
[17:27:07] <dstufft> I've been using warehouse.p.o full time to try and iron out bugs and annoyances, I forget about it when I link it to folks :]
[17:28:46] <dstufft> my ``python`` is Python 3.4 and I do all my development in Python 3.4, but I support all the way back to 2.6
[17:29:11] <dstufft> zyga: Probably just nobody has ever done it. I more or less ignore the downstream packages and let them do their thing
[17:29:27] <zyga> dstufft: right, that's the difference, I took some debian code lately and threw 2.x support away, as I only need it to work on 3.2+, it is really refreshing when you can do that
[17:43:39] <zyga> dstufft: so looking at warehouse.p.o how do I get the upstream signing key and where is the signature itself
[17:44:40] <dstufft> zyga: the signature itself should be in a (pgp) link after the filename (look at sdist on https://warehouse.python.org/project/cryptography/)
[17:45:20] <zyga> dstufft: https://warehouse.python.org/packages/source/t/twine/twine-1.3.0.tar.gz.{pgp,asc} would be lovely
[18:05:13] <dstufft> The PGP key fingerprint is on https://caremad.io/about/ if that's easier for you
[18:05:41] <zyga> dstufft: does twine make sense as a library (so that python2 and python3 versions can be co-installed) or just as an executable?
[18:06:15] <dstufft> zyga: a few people want to use it as a library and have submitted PRs to make it act like that, but generally I think it's mostly useful as an executable
[18:06:58] <zyga> dstufft: I see that python-pkginfo has no python3 version at the time (in Debian) and is pretty old (0.9.1)
[18:54:24] <zyga> dstufft: do you think you could quickly write a few words (specifically for the man page)
[19:09:23] <zyga> http://bazaar.launchpad.net/~checkbox-dev/checkbox/trunk/view/head:/plainbox/docs/manpages/plainbox.rst
[19:10:20] <zyga> dstufft: look at man git man git-$foo for hints (since you seem to follow the same dispatcher->subcommands style
[19:10:37] <dstufft> zyga: Ok, I'll see what I can do. I'm up and down for easter stuff atm so it might take awhile
[19:10:41] <zyga> dstufft: then when you get that just add a few lines to conf.py: http://bazaar.launchpad.net/~checkbox-dev/checkbox/trunk/view/head:/plainbox/docs/conf.py#L238
[19:11:30] <zyga> dstufft: the hint in the conf.py comment tells you what to put in man_pages = there
[19:12:05] <zyga> dstufft: BTW, pip could be much better to promote having man pages if pip install --user foo would enable the manpages done by foo (and build them if there's some hint they exist)
[19:12:47] <dstufft> I tried using Ubuntu on my Desktop ~2 years ago or so and got really frustrated
[19:12:53] <zyga> dstufft: man pages are great, despite what all the 2.0 ajax css magic people tell you ;)
[19:13:48] <dstufft> I don't know how to navigate them other than hit spacebar and often times I go too far and idk how to go backwards
[19:14:14] <zyga> dstufft: --help is good but a dedicated man page can give a lot more context and insight
[19:14:48] <zyga> dstufft: (when you have a few hours to burn, read perl man pages, man perl is the index, it's a bit crazy but you can learn everything just from the man pages there
[19:15:12] <dstufft> yea I understand why they're useful, I just don't use them because the UI has frustrated me :]
[19:15:17] <Alex_Gaynor> I guess there is one time I use man pages: random C functions and syscalls.
[19:15:19] <zyga> dstufft: anyway, thanks for twine, I'll send RFS to my sponsorts to get twine and requests uploaded to sid
[19:16:06] <zyga> Alex_Gaynor: system level software and developer software is expected to carry man pages for all the system engineers that really expect man/apropos anything
[19:16:42] <Alex_Gaynor> The assosciation between `man` and OpenSSL doesn't really do `man` any favors.
[19:17:48] <zyga> dstufft: being in python for so long made me learn assembly and work on embedded stuff (no-os type embedded)