Log file Viewer
#pypa logs for Friday the 7th of March, 2014
[08:01:24] <ronny> btw, any chance we can get a variant of pip/virtualenv that will have the venv be reduced to a pth files that lists editable installs and wheels?
[11:26:38] <Ivo> dstufft: do you know if you have this setting checked for packaging-problems? http://i.imgur.com/jUlzuT6.png
[11:46:14] <Ivo> ronny: fork pip, clone it, make sure you can run tests (tox and py.test), put up an issue properly explaining the feature you'd like to implement (alternately, maybe this is primarily a virtualenv feature, not pip?)
[11:48:37] <ronny> Ivo: bot tools, since well, its basically a new kind of virtualenv, and pip would basically handle drop to where
[11:52:50] <Ivo> ronny: stating the problem you're trying to solve is usually better than simply stating a solution you've formulated to it
[11:57:07] <ronny> Ivo: no, i want something where a virtualenv is difined as a list of already unpacked whhels that are stored in a global location per user/system
[12:04:00] <ronny> Ivo: i.e. a "virtualenv" that bascially only consists of something like a single pth + the scripts
[12:06:01] <Ivo> you can already have a local database of wheels, and just tell pip to install x, y and z from them with a requirements and --find-links
[12:06:42] <ronny> Ivo: i want less files, basically in a projet i want a scm ignored bin directory and a scm ignored pth directory, and viola virtualenv
[12:07:39] <Ivo> ronny: all your virtualenvs, out of your way, in some folder like ~/.virtualenvs (or where you'd like)
[12:08:21] <Ivo> dstufft: would you be able to go to https://github.com/pypa/packaging-problems/wiki and spam some test and click save or w/e?
[12:09:38] <Ivo> ronny: It's worked absolutely fine for me for a year developing all sorts of stuff, so I don't regard it as fragile at all.
[12:11:01] <Ivo> i type mkproject prgname and i get a new empty folder at ~/code/prgname with the isolated python i want
[12:16:08] <ronny> but the mroe i work with it, the more i find the local installs annoing, i really only want the scripts, and a pythonpath confgurations
[13:35:03] <Eraser_2014> i ask that question cuz i dont finda any info how to upload packages to warehouse
[13:54:32] <Ivo> I'd only use it if it turned out there were no other pypi-mirror-like applications that bothered to implement the xmlrpc
[14:13:33] <Ivo> Eraser_2014: as a workaround, why do you need puppet to be able to talk to a custom pypi over xmlrpc?
[14:14:24] <Ivo> Eraser_2014: have you tried just installing a .pypirc with a different index (or using the envvar or the cli flag) and then tell it to pip install things manually?
[14:15:51] <Ivo> Eraser_2014: you might consider writing an alternate module to use the json api? I'd guess a mirror would have implemented that
[17:03:09] <qwcode> dstufft, Ivo I'm conflicted on this https://github.com/pypa/packaging-problems/wiki
[17:03:31] <qwcode> I really don't 2 future pages. I think all of this could go onto the future page
[17:04:41] <qwcode> to accomodate the structure no this wiki page, we could break down the PUG Future section into categories instead of by year and TBD
[17:04:55] <Ivo> here's how I think of it - as a whiteboard for many people to collate their thoughts on (if many people do, otherwise I can move it off to somehere for myself). PPUG as a repo is not as condusive to that, as a repo, and also wants to only put 'correct' information out, rather than ideas
[17:05:48] <dstufft> qwcode: yea I suggested Ivo contact you about it, since it looked like it had some overlap but I'm not real up on what ppug is doing
[17:06:23] <Ivo> I think of ppug as user facing, and this as essentially not user facing, and therefore freer
[17:08:06] <qwcode> the future page is supposed to offer insight into what the developers are planning. planning is a process. it doesn't have to be the end point of planning, i.e. when we're sure exactly how things are going to go. that's rarely true anyway
[17:08:09] <Ivo> we are already discussing most of this stuff in mailing lists / issues everywhere and hashing out correct things to do in single instances, but to me having a central place to put stuff for the people involved in trying to improve is a good idea. I presume, maybe it would be for others
[17:09:27] <qwcode> Ivo, again, I think a number of the bullet points are really good, I just want the future page to be more controlled, and I don't want 2 of them to have to sync
[17:10:41] <Ivo> I'd thought of the Future page as something saying "Yes, this is what PyPA is doing in the future", and also a record of sorts; I wanted a page to collate ideas, but without that explicit promise
[17:12:47] <qwcode> Ivo, we can put a disclaimer on the future section. I'd rather people see the truth than only the minimal things that we think are solid of enough to commit to
[17:14:41] <Ivo> qwcode: secondary thing i wanted is a page of links to relevant discussions and issues as they come, so I don't have to find them again every time
[17:17:25] <Ivo> I'd thought maybe this could be useful for others which is why i put it in package-problems wiki, but I could be presumptious about that, in which case please do say :)
[17:17:33] <qwcode> Ivo, the future page can rattle off the the most relevant links related to the things it lists
[17:19:03] <Ivo> heh, daenney's 5th dot point is what I was thinking https://github.com/pypa/packaging-problems/issues/21#issuecomment-37043190
[17:19:17] <qwcode> Ivo what you're doing is useful, I would just prefer it channeled into the PR controlled PUG future page.
[17:20:56] <dstufft> What qwcode is saying seems reasonable to me FWIW, when i first saw the wiki page it looked like it had overlap
[17:21:57] <Ivo> personally, i see them as having different audiences, and the editable wiki format being preferable
[17:24:34] <qwcode> Ivo, you're page right now for me is a mixture of: 1) "cool, that should be on the future", 2) "yea, we should organize the future page more like this", 3) "that bullet point is wrong, don't like it in an official pypa repo", 4) "what does that mean?"
[17:27:33] <Ivo> but I think 3) is a part of the process. People have wrong ideas, and right ideas, and debatable ideas, for me its nice to have them down in a place which isnt yet another PR Issue thread
[17:30:06] <Ivo> qwcode: for instance, do i start submitting prs to the future page now, or do you have ideas about restructuring it first?
[17:31:29] <Ivo> qwcode: and as if anybody reads wikis of obscure pypa repos anyway, they hardly look at betas of products :P
[17:32:31] <qwcode> Ivo, so instead of "2014" and "TBD" under future, let's do a categorical thing like you're doing.
[17:34:10] <qwcode> Ivo, the concern is both that I don't want redundancy, *and* that I want all the energy to go to the future page. I want it to be good
[17:37:34] <qwcode> Ivo, yea, eventually "completed" will be too big, and should likely be a link off, or just not be there, but for the moment, I'm wanting to highlight that the "new order" is getting stuff done
[17:42:04] <Ivo> it's just like, almost all the sections could be expanded in the Future page atm, after all the work we've done trying to hash out details of things rather than having rough ideas (although there are still many rough ideas to get through), and if it were, it'd be a huuuge page atm
[17:44:30] <dstufft> I'm fairly aware of what time it is in Australia because daytime down under is about the only time Richard is around to talk to
[17:46:05] <qwcode> Ivo, thinking the "could be expanded" should all be done per issue in their respective issues.
[17:48:12] <Ivo> qwcode: but i dont want to expand them as they are because itd make the page just as hard to read as it is to sort through my brain atm
[17:58:18] <qwcode> Ivo, if you want to compile notes, that's ok, but I don't want it un-reviewed on a pypa repo (that's my personal opinion) I admit to wanting all high-level public pypa planning effort to go to the PUG.
[17:59:11] <Ivo> qwcode: I think its ok if its on a repo and if it makes a disclaimer saying "really these are just public ideas" :)
[18:00:25] <qwcode> Ivo: I don't think a public pypa wiki shouldn't have this: "Disclaimer: currently an overview by Matthew Iversen, not at all the canonical opinion of the Python Packaging Authority."
[18:01:10] <qwcode> tomprince, I want public, just want the one page we already have for future stuff
[18:01:41] <Ivo> qwcode: thats mainly because its only written by me atm, so even though I wanted to share it with pypa for people to edit, I didnt want anyone to get the idea that itd gone through pypa's approval
[18:02:24] <Ivo> If some people edited it, I would've like to change it to "these are priliminary ideas of pypa"
[18:05:27] <qwcode> Ivo, I'm not sure what else to say. I've made my piece on this. I'm going the route of the PUG future page (with the revisions I've mentioned from having this discussion). I'd prefer not to have 2 efforts (that I see as overlapping).
[18:10:04] <qwcode> Ivo, it's one thing to be given public wiki access, and then use it to organize the content of the "packaging problems", but it's another matter to go further and label it as the "Roadmap towards better Python Packaging"
[18:10:57] <Ivo> jason wanted a more positive name than "Wiki of Packaging Problems" so I changed it to that :)
[18:11:44] <qwcode> Ivo, again, I want your effort, but "greedily" want it on the PUG. that's the thing we've been trying to establish for people as "the" thing.
[18:13:04] <qwcode> Ivo, and although it's largely been just me doing it, I'd really like to see the future become something that's a peer-reviewed planning page, that can be taken more seriously
[18:13:07] <Ivo> I love the pug as well, I just have always seen it as an "end product" with only good recommendations, not things that might turn out to be wrong or a scratchpad
[18:14:36] <qwcode> Ivo, in an ideal world I guess, you could have both, but practically, there's only so much oxygen in python packaging.... (like in an ideal world, we can have multiple wheel implementations, but is it practically good for us?)
[18:15:56] <Ivo> my conception was that people could put up ideas and directions in one place, and once everyone had mostly agreed on x, it would be something to migrate to a dot point on the future page and hopefully start implenting
[21:15:15] <Ivo> huh, just noticed that PUG has somehow managed not to have a "Where to get help or ask someone" page