#python-requests

/

      • badon has left the channel
      • rbrud has quit
      • rbrud joined the channel
      • rbrud has quit
      • rbrud joined the channel
      • badon joined the channel
      • rbrud has quit
      • rbrud joined the channel
      • rbrud has quit
      • rbrud joined the channel
      • Crys joined the channel
      • kevinburke has quit
      • shiriru joined the channel
      • shiriru has quit
      • d3Meq has quit
      • d3Meq joined the channel
      • smidlers has quit
      • lukasa
        kennethreitz: *we* cannot flip a switch
      • Because Requests is under your namespace, which means only you have admin
      • So, forgive me if I'm paranoid here, but the last time we had a Jenkins it broke and was broken for months
      • This time we've doubled down because the Jenkins is now guarding access to the master branch, which means if it breaks literally the only person who can unstick the project is you.
      • I am *extremely nervous* about the bus factor involved in that
      • smidlers joined the channel
      • d3Meq has quit
      • d3Meq joined the channel
      • lifeless joined the channel
      • sigmavirus24
        lukasa: worse, kennethreitz is going to operate the server out of his house? Which means if/when it loses power not only will it be completely useless to us as a project, it won't be fixable by anyone but kennethreitz and if disks fail, no one can fix it but kennethreitz
      • If we had the project in an organization, that'd be great because you or I could swap over to something else
      • but as long as this is kennethreitz's art project and not core Python community infrastructure, it seems this will always live under github.com/kennethreitz
      • willingc joined the channel
      • kennethreitz
        I'd consider moving the repo to the org
      • And I can always return the server, I just wanted faster build times and something to hack on
      • willingc joined the channel
      • nateprewitt joined the channel
      • willingc has quit
      • willingc joined the channel
      • sigmavirus24: thought that'd make you smile :)
      • should have happened a while ago
      • i'll move requests-oauthlib over too
      • i think there's a balance for requests to be both reliable infrastructure for the python community and a kennethreitz art project
      • the two aren't mutually exclusive
      • dstufft
        kennethreitz: I think probably that balance likely needs to include not making breaking changes on a whim though? I mean, I'm personally happy to see requests start to have "real" dependencies, but as an example-- having a random minor release start unbundling things forseeably broke things for folks, and people tend to start to shy away from "core" projects that seeminly break them at random.
      • just an observer's opinion though ^
      • (using my own experiences with an equally important project)
      • I certainly do some some rumblings about looking for alternatives to requests in some Python centric channels/projects/etc going on. I wouldn't say it's a major groundswell or anything, but folks do feel a bit like the rug got pulled out from underneath them.
      • kennethreitz
        dstufft: that was definately an accident, oversight on my part
      • luckily the backwards incompatibility was only out for about 8 or 9 hours
      • i've never once told anyone to use internal packages in their code, so i wasn't aware they were a trusted api for some people
      • but corey and ian it turns out have been telling people to use them for years
      • dstufft
        kennethreitz: sure! Accidents totally happen :) I'd guess my advice can be boiled down to not landing archiectural changes then immediately cutting a release before you get a chance for someone else (probably lukasa or sigmavirus24) to give it a second set of eyes to make sure they don't see anything major.
      • kennethreitz
        yeah
      • i get keyboard happy sometimes :)
      • requests used to ship broken changes all the time though, wasn't really a huge deal
      • i'd just cut another release immediately after that fixed it
      • no one ever noted
      • *noticed
      • dstufft
        Yea, the impact of that starts to scale expotentionally with the number of users you have I've found heh
      • kennethreitz
        i really want pipfile for pip btw!
      • if there's anything i can do to help accellerate that, i'm down
      • pipenv is totally not appropriate for ci and friends
      • and pip is really what people need
      • dstufft
        kennethreitz: Yea, it's on my stack to get back around to :/ The good news is, we have a GSoC student for pip this year who is going to be working on a real resolver, so with that work, integrating something like Pipfile should be a ton easier
      • kennethreitz
        \o/
      • that'll be dope
      • dstufft: do you maintain setuptools?
      • dstufft
        kennethreitz: No, jaraco // jason coombs does setuptools. I techincally have a commit bit by nature of being a pyca admin on github, but he's the maintainer
      • kennethreitz
        i really hate the new dependencies
      • they really fuck things up for heroku
      • dstufft
        Yea, there's an open issue about that
      • I'm not a fan
      • kennethreitz
        because people put appdirs and six into their requirements and they're older versions sometimes
      • it'd be nice if you could do....
      • pip install -r r.txt --ignore=six,setuptools,appdirs
      • dstufft
      • I'd suggest chiming in on that
      • kennethreitz
        thanks!
      • dstufft: i had a great discussing about you with guido at pycon over dinner last week
      • he made a great observation that i'd like to talk to you about
      • something i could maybe help out with
      • he thinks you don't delegate enough
      • and i think that's a documentation problem, potentially
      • like, more people could get involved and help you do what you do if we wrote down (give people permission) to help you out in their unique ways, if that makes sense
      • btw appveyor refunded my $50 without even asking me! very nice of them
      • dstufft
        kennethreitz: Yea, delegation is absolutely something that I struggle with. My HPE manager had it as one of my goals to do more of it :V -- Warehouse is doing -better- in this regards, there's @di who has commit bit there and Nicole more or less completley handles the design side of things. It's also pretty well documented I think for people to jump in. Pip is.. harder. The code base is a mess so people tend to get scared away by it
      • kennethreitz
        i still haven't heard back from travis about my $250
      • dstufft: well i'd love to help contribute "how to help donald" docs sometime!
      • dstufft
        (I'm hoping that once Warehouse is "live", more people will be incentivized to contribute since it'll be deployed to the thing everybody uses which is cool feeling).
      • kennethreitz
        dstufft: oh one other thing
      • dstufft: so can warehouse expose hashes for all files avaiable for a package over the api?
      • dstufft: i want to make pipenv store hashes for all files available, so the lockfile will work cross-platform
      • dstufft
        kennethreitz: it already does, the URLs has #sha256=...
      • kennethreitz
        in the json api? fantastic
      • i haven't taken a close look yet
      • i assumed it would have had to be added
      • dstufft
        oh in the JSON API, yea it's there too, it's a key in the JSON structure
      • kennethreitz
        :D
      • that'll make locking so much faster too, we're currently downloading the files
      • to get the hashes
      • dstufft
        note that the JSON api is specific to PyPI so it won't work with custom indexes
      • the /simple/ API is the standard API
      • kennethreitz
        that's fine for 98% of peeps
      • dstufft
        Yea, it's not wrong to use the JSON api, I was just making sure you were aware incase you wanted this to be used with custom repos
      • kennethreitz
        one thing i was thinking of doing with this server is running a cheeseshop mirror
      • what was the name of that tool again for doing that?
      • sorry for all the questions, i got a lot of them in my head at pycon and now you're here :) :P
      • dstufft
        bandersnatch is full mirror that gets kept in sync with a cron job, devpi is an on demand mirror (so smaller space) and also includes the ability to have your own custom private packages (among other things)
      • if you _just_ want a full mirror and can spare a few hundred GB, bandersnatch is better
      • kennethreitz
        bandersnatch is what i was trying to remember
      • dstufft: will pip's dep resolver allow me to say something like pip.resolve('requests') and get back a list of dependencies with versions?
      • dstufft
        kennethreitz: API is TBD (and a re-usable implementation is a stretch goal). So I can't specifically answer that, but the goal is to eventually make this either it's own library, or part of the packaging library
      • long term the goal is that all of the bits of pip that tools like pipenv might want to interact with, get pulled out of pip and into real libraries, then pip just consumes those libraries and adds the interface and the glue between them
      • kennethreitz
        fucking fantastic :)
      • dstufft
        doing it this way lets us divorce the idea of what a good API is from what is easiest with pip's code base, and then we refactor pip to support the library rather than the other way around. It also makes it really hard to accidently expose private bits of pip as part of the "API"
      • kennethreitz
        the pip codebase is so bad :)
      • i'm so impressed with it!
      • bad meaning complex
      • dstufft
        it's also just pretty bad. A lot of spaghetti exists there
      • kennethreitz
        didn't want to be offensive :)
      • i tried adding pipfile support
      • and i just couldn't even come close to approaching that problem
      • dstufft
        yea, it's _really_ hard for people to get started with pip, because it's really poorly factored
      • kennethreitz
        the pipenv codebase is nice, but also hard to make sweeping changes to, fwiw
      • sigmavirus24: what do you think about addding requests-toolbelt to the org too?
      • shiriru joined the channel
      • shiriru has quit