Log file Viewer
#pypa-dev logs for Friday the 24th of April, 2015
[02:20:11] <lifeless> dstufft: I'm thinking I could make some internals a bit nicer if the build dir was treated as a cache
[02:21:19] <lifeless> dstufft: vs the current thing where we delete individual req's out of it based on whether an error was encountered processing it or not
[02:27:01] <dstufft> lifeless: also I think it's OK to delete the whole thing (or not delete if --no-clean)
[02:51:54] <dstufft> lifeless: can I get you to commit --amend and force push? github doesn't update the diff when things get merged so this diff has 2699 in it still :/
[03:17:20] <dstufft> lifeless: cool, will take a look in a few minutes, going through the open tickets to try and see if we can close out any of them or if I can comment on anything
[03:17:41] <lifeless> dstufft: cool; there's been more discussion on the other release-blocker tickets
[03:19:24] <dstufft> we're not super strict about the release blockers, often I just use it as a way to remind myself of issues to look at before cutting a release
[03:27:10] <dstufft> lifeless: pbr doesn't support any sort of option to build a "static" sdist which doesn't depend on pbr does it?
[03:30:33] <lifeless> dstufft: obviously we could, but I'm kindof philosophically against having sdist replace the contents of files that are in VCS
[03:31:56] <dstufft> lifeless: going through pip I was reminded of my tickets to automate the release of pip and such, I don't want a setup_requires in pip though so anything we add will need to generate a "static" sdist
[03:34:24] <dstufft> lifeless: yea that's an option, didn't think of that since it wouldn't be a runtime dep really
[04:10:30] <lifeless> dstufft: https://github.com/pypa/pip/issues/2675#issuecomment-95787332 <- I think you meant 2699 ?
[04:12:41] <lifeless> /home/travis/build.sh: line 41: /home/travis/virtualenv/python2.7/bin/activate: No such file or directory
[04:22:58] <lifeless> I suspect test ordering and deprecation warnings not being isolated in the test suite
[04:55:00] <lifeless> dstufft: You likely use your PC for more than just hacking. Most notably, you likely use your PC to browse the Internet and download software. Software is buggy. Buggy software has exploits and exploits tend to get, well, exploited. Not every developer has a strong understanding of the best security practices for their operating system (if you do, great!). And no---simply using GNU/Linux or any other *NIX variant does not make you
[20:47:50] <sigmavirus24> when did comma change to "logical and" from "logical or": https://www.python.org/dev/peps/pep-0440/#version-specifiers ?
[20:50:28] <dstufft> it was never a logical OR, it was a complicated ruleset that sometimes meant OR and sometimes meant AND
[20:56:22] <dstufft> ronny: sure, people who prefer Hg likely will be opposed to it :) People who prefer git will like it.
[20:59:45] <dstufft> sigmavirus24: while I certainly agree with that, I don't think it's as important as the fact you're going to be hard pressed to find someone in OSS who isn't familar with git to a workable degree, and for new users who are learning, learning git is more likely to ve useful knowledge in the *next* project they work on
[21:07:12] <ronny> sigmavirus24: actually with the stuff facebook did on hg, hg is faster than git ^^
[21:08:07] <sigmavirus24> ronny: and how many people actually use that extension? does mercurial build wheels/installers with that extension now?
[21:08:30] <sigmavirus24> Also has mercurial stopped trying to claim that using its api to build extensions makes that work GPLv3?
[21:12:00] <pjdelport> I feel the need to point out that human factors should also be considered in any comparison between hg and git.
[21:12:42] <pjdelport> Regardless of which one is faster at certain benchmark operations, which one is faster and more efficient at being used by human developers?
[21:12:47] <dstufft> ronny: eh, even facebooks own graphs show that without remotefilelog clone and pull are still faster in git than in hg. the file status stuff requires a persistent watchman process to send the inotify too
[21:13:09] <dstufft> pjdelport: That's going to depend on which one the person is most familar with :)
[21:13:33] <dstufft> I'm really familar with git, I'm about as fast with it as I can be with a VCS until one learns to read my mind
[21:13:46] <ronny> dstufft: i dont mind trading some ram and cpu for more speed of a hackable tool ^^
[21:14:03] <dstufft> I'm not familar with hg at all, I use hg diff and aptch to implement branches because I can't be assed to figure out which one of mercurials 6 types of branches are the right kind to use
[21:14:31] <pjdelport> dstufft: I'm very familiar with both, and the relative limitations and user-hostility of git constantly pains me. But yeah, obviously mileage varies.
[21:15:07] <pjdelport> dstufft: If you want git-style branches in Mercurial, you want bookmarks, FWIW.
[21:15:32] <dstufft> pjdelport: someone said that, but then they told me they all live in the same namespace or something so I have to be careful to not clash or something
[21:16:02] <dstufft> and I got yelled at both by Mercurial itself, and by the project I was trying to submit a PR too for using real named branches
[21:17:33] <dstufft> I don't want to learn hg and I'm fine using my horrible hg diff hack because I only work on one project where I use hg (well two if you count PyPI, but we odn't use branches and I'm moving that to git anyways) so it doesn't effect me much
[21:17:36] <ronny> i strongly prefer hg, because compared to git extension hacking is way more easy once one knows the "plumbing"
[21:17:54] <pjdelport> I wouldn't say mostly; Mercurial has several what I consider to be killer features that have no git equivalent. Named branches and revset queries, for starters.
[21:19:25] <ronny> dstufft: you can do something like hg log -r 'modifies("src/**") and not merge() and not modifies("src/evil.c")'
[21:19:27] <pjdelport> dstufft: Well, named branches mean you can look at the history and actually see what branches were where. If you don't care about having a readable history, they won't be very useful.
[21:19:51] <dstufft> pjdelport: my history is plenty readable with git, I just don't think the branch name is a useful bit of information
[21:20:17] <dstufft> I think I've cared about what branch a commit was originally on all of once ever
[21:20:20] <ronny> pypy has between 10 and 40 long lifed active branches - and over 800 historic branches, without branch names one would be utterly lost
[21:20:45] <ronny> and the branch context was regulary needed for blames/lookups to understand the context of a commit
[21:21:11] <pjdelport> dstufft: Well, whether one cares about branch names or not depends; but the point is that hg gives you the option of using them. With git you're just out of luck.
[21:21:44] <dstufft> pjdelport: you can record them with git if you want, *shrug* a tiny commit hook can shove it in the commit message as a field jsut liked Signed-Off and such is
[21:22:40] <dstufft> I can't think of anything useful I'd want to do with a branch name :) half the time my branch names are non sensical until I've made a few commits anyways
[21:22:48] <pjdelport> The point of having it as first-class metadata is that you can see it easier, and that you can do stuff with it.
[21:24:07] <pjdelport> Which is a revset query for all changeset matching foo that are included in branch "feature" but not in stable.
[21:24:33] <ronny> lifeless: now, find all hotfies between 2 tags, some commiters however didnt add that in the commit message, it still was a branch once
[21:26:52] <ronny> lifeless: usually nothing, where i work hotfixes are mandatory to be on the hotfix branch
[21:27:21] <ronny> hat branch is fixed in history, so its eay to query for all commits that hapenend only in hotfix
[21:27:24] <lifeless> ronny: so you have a workflow process where commits that are going into a stable branch have to be done a special way
[21:29:04] <lifeless> huh, that surprises me - for all the projects I'm involved with, when there is a stable branch, its locked down, only hotfixs go there at all
[21:29:05] <ronny> bascially we have a proess similar to hg + a hotfix branch when important issues come from production
[21:30:27] <ronny> at what we do stable is what will conclude the next delivery, hotfix is for immediate changes to the crrent delivery
[21:35:07] <dstufft> ronny: I don't think it's much difference between "it's mandatory tthat we name branches a special way" and "it's mandatory we add a special header to hte commit message"
[21:38:12] <dstufft> a key differnce is you can only have one branch name, but you can have multiple header like things inside of a commit message