PMXBOT Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Wednesday the 12th of June, 2019

(Back to #pypa-dev overview) (Back to channel listing) (Animate logs)
[06:04:39] <Ivo> when de-vendoring is a great idea /s https://media.discordapp.net/attachments/451312046647148554/588242712382275594/unknown.png
[06:05:53] <Ivo> debian 9
[06:07:31] <pombreda> Ivo: WTF? why would pip vendored code endup importing some random package that you installed locally?
[06:08:30] <Ivo> it's not some random package
[06:08:35] <pombreda> hum, pip vendors distro and somehow
[06:08:37] <Ivo> it's debian devendored package
[06:09:04] <Ivo> because devendoring is important to reduce code duplication
[06:09:35] <pombreda> yeah... if you consider package duplication to be a bigger problem than code stability :D
[06:09:41] <pombreda> Ivo: ;)
[06:10:09] <pombreda> there is a reason why pip vendors certain packages IMHO
[06:10:23] <Ivo> I'm sure there must be some less strawman reason than that... but anyway...
[06:11:24] <pombreda> Ivo: so your point was that devendoring is a great idea? of was it sarcastic?
[06:11:29] <Ivo> someone in a help channel just posted that, was wondering whether to explain all the mechanics about why their OS is the cause of a pip error that'll be hard to fix
[06:11:32] <pombreda> *or
[06:11:33] <Ivo> sorry, sarcasm
[06:11:45] <Ivo> ...or just vent in here
[06:11:51] <pombreda> fair enough :P
[06:12:50] <pombreda> I was about to lecture you about why here the package deconstruction made by distros is not clearly counter productive
[06:13:02] <pombreda> *is clearly
[06:15:11] <pombreda> Ivo: I am starting to think that there are really very cases where this is a valid excercise
[06:15:20] <pombreda> both a time waste to craft the distro packages at first and then you are sure to meet byzantine bugs down the road
[06:16:01] <pombreda> so a clear loose-loose to me: you waste time twice and get nothing got out of it
[07:42:07] <njs> pombreda: distro maintainers still have scars from the first time there was a major security bug found in zlib, and then everyone discovered that they had like, hundreds of vendored copies that all had to be fixed individually
[07:42:36] <njs> pombreda: the way they mess with pip and don't coordinate at all with upstream is pretty annoying, but there is a logic to it as well
[10:29:19] <pombreda> njs: true. I wish we could have it both ways :)
[17:48:19] <sumanah> dstufft: hey did you ever wrap up any of your retention research for https://github.com/pypa/warehouse/issues/3532 ?
[18:18:00] <sumanah> EWDurbin: di_codes dstufft this isn't urgent, but I'd love to update the social image for pypa/warehouse to be the PyPI logo - https://github.com/pypa/warehouse/settings -- that makes it so when you embed/link to an issue/PR/etc within the repo, the favicon isn't just the GitHub logo
[18:18:04] <sumanah> Images should be at least 640×320px (1280×640px for best display).
[18:56:27] <techalchemy> i'm currently at a snapcraft event hosted by canonical & would be happy to build snaps for anyone who wants one up
[19:02:10] <apollo13> I'd give a kingdom for a snap that doesn't autoupdate
[19:02:24] <apollo13> that is literally stopping me from using snaps :/
[20:17:33] <techalchemy> apollo13: why ?
[20:17:43] <apollo13> why what?
[20:18:02] <apollo13> I cannot just upgrade apps, I need a timewindow etc…
[20:18:10] <apollo13> also autoupdates that break your apps are great…
[20:18:54] <apollo13> techalchemy: don't get me wrong, I like most things snaps do, but some (server environments) can't just have stuff autoupdating all over the place
[20:23:47] <techalchemy> ok i am not making snapcraft, i don't work for ubuntu
[20:23:58] <techalchemy> i am specifically packaging python packaging authority libraries in snaps
[20:26:13] <apollo13> techalchemy: does that even make sense for stuff like pip etc?
[20:26:51] <apollo13> the way I understand snaps they are mostly isolated so you couldn't really use it to install stuff in a useful way? or what were you thinking about?
[20:27:27] <techalchemy> huh?
[20:27:39] <techalchemy> the snap itself is isolated
[20:27:52] <techalchemy> it works fine
[20:28:14] <techalchemy> my question is for the maintainers of the involved applications about whether they would like me to package things for them
[20:28:44] <apollo13> yeah but package what in a snap? pip?
[20:30:27] <sumanah> techalchemy: thanks for the offer! I'm wondering whether it might make sense to build one for one of the tools that we want to run in lots of different environments, for CI-type testing purposes
[20:31:17] <techalchemy> sumanah: not sure what you mean--travis has people here though so that's probably a use case
[20:31:21] <techalchemy> virtualenv might be a good candidate
[20:31:53] <techalchemy> in general though it would give us control over the distribution releases of our own packages for people using snaps, including things like pip
[20:32:08] <techalchemy> so we can update people without conflicting with whatever debian needs for its own system etc
[20:32:34] <apollo13> I am trying to understand here, but pip usually installs into the python itself got installed into. A pip in a snap would have the python from within the snap?
[20:32:39] <apollo13> or how would that work?
[20:32:58] <apollo13> might be just that I do not see the wood due to all the trees though
[20:33:03] <techalchemy> right
[20:33:22] <techalchemy> pip would respect the user's environment and install things there.
[20:33:36] <sumanah> so I can't speak to what other maintainers might want -- techalchemy about how much time is left at this event? not sure you're going to get responses from other maintainers within that window
[20:33:44] <apollo13> but how would it know the python version the user uses outside of the snap?
[20:33:59] <techalchemy> apollo13: trust me that it is possible please.
[20:34:22] <apollo13> I am not trying to disagree, I am trying to learn something :(
[20:34:26] <sumanah> apollo13: btw hi I'm Sumana, I work on Warehouse mostly. What are you working on these days? (sorry if I have forgotten)
[20:34:26] <techalchemy> sumanah: sure about a day or so, no worries I can experiment with building some examples
[20:35:05] <apollo13> sumanah: haha, no worries -- still mostly django and lurking around here :)
[20:35:49] <sumanah> apollo13: so you're interested in becoming a PyPA contributor? (I presume that's what people lurk here to do)
[20:36:01] <sumanah> I'd be happy to get your help on an open issue
[20:36:12] <techalchemy> apollo13: python --version, python -c 'import sys; print(sys.version_info[:2]))', there's a way to make external calls as well
[20:36:17] <sumanah> Warehouse uses Pyramid, not Django, but you can learn that
[20:36:24] <apollo13> thanks for the offer, but I am wearing to many heads already ;)
[20:36:39] <techalchemy> but snaps installed in classic mode by default will use paths from the users environment
[20:37:04] <sumanah> ok. apollo13 thanks for clarifying that you were asking to learn, not disagreeing -- it was hard to tell, initially
[20:37:07] <techalchemy> i'm sitting in a room with the people who wrote the tool so if it's possible we cacn make it happen
[20:37:43] <sumanah> And thanks for working on Django!
[20:39:44] <apollo13> techalchemy: I guess I have to look more into classic mode then, the things I wanted to use snaps for were mostly self-contained on purpose, ie running with strict confinement (or whatever it is called these days)
[20:40:40] <apollo13> sumanah: thanks, but that is nothing compared to the work you folks are doing on pypi
[20:40:58] <sumanah> awww shucks :) thanks
[20:41:04] <techalchemy> apollo13: that's the one. strict confinement may be able to do these things but classic confinement is fundamentally different in one important way
[20:41:42] <techalchemy> apollo13: for strict confinement, your path is $SNAP/usr/sbin:$SNAP/usr/bin:$SNAP/sbin:$SNAP/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
[20:42:00] <techalchemy> in classic mode you don't have the $SNAP prefixed paths
[20:42:25] <apollo13> yeah and also more generally access to the whole filesystem around I assume?
[20:50:23] <techalchemy> yup