PMXBOT Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Wednesday the 1st of April, 2020

(Back to #pypa-dev overview) (Back to channel listing) (Animate logs)
[00:27:29] <travis-ci> pypa/pip#15376 (master - 895fe94 : Pradyun Gedam): The build passed.
[00:27:29] <travis-ci> Change view : https://github.com/pypa/pip/compare/534561cbecb6...895fe94240f0
[00:27:29] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/669474706
[02:04:45] <cjc7373> !logs
[02:04:45] <pmxbot> http://kafka.dcpython.org/channel/pypa-dev
[13:09:53] <travis-ci> pypa/pip#15383 (master - 0c30b45 : Pradyun Gedam): The build passed.
[13:09:53] <travis-ci> Change view : https://github.com/pypa/pip/compare/895fe94240f0...0c30b45ce2a3
[13:09:53] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/669671363
[13:11:49] <travis-ci> pypa/pip#15384 (master - 7b02273 : Pradyun Gedam): The build passed.
[13:11:49] <travis-ci> Change view : https://github.com/pypa/pip/compare/0c30b45ce2a3...7b02273f3e40
[13:11:49] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/669672359
[13:13:10] <sumanah> there are a lot of hard problems that lots of us are trying to work on! This is true and has been true but I just felt the weight of it more keenly this moment.
[13:25:13] <devesh> Hi Folks, I had a question about resolving conflicts in a PR
[13:29:27] <pradyunsg> sumanah: hmm... what happened that made you feel this? :o
[13:29:43] <sumanah> devesh: go ahead! what's your question?
[13:29:51] <pradyunsg> devesh: go ahead and ask.:)
[13:30:15] <sumanah> pradyunsg: today, I went on Hacker News and searched for "pip"
[13:30:34] <sumanah> I do not recommend this step to anyone who is feeling a bit aieeee already
[13:30:38] <pradyunsg> sumanah: oooo
[13:30:53] <sumanah> ("aieee" is not a technical term)
[13:30:56] <sumanah> (more of a mood)
[13:30:59] <pradyunsg> hehe
[13:31:14] <pradyunsg> sumanah: Yea, I'm not going to do that -- not with the current mental state I'm in.
[13:31:23] <sumanah> Good choice!
[13:31:38] <devesh> So I saw that there is a file which was updated recently in master, and on which I have made changes, on a version before
[13:32:42] <devesh> The updated file is https://github.com/pypa/pip/blob/master/docs/html/reference/pip_install.rst and my PR is https://github.com/pypa/pip/pull/7938
[13:33:05] <devesh> So how can I make sure that when I change this file on my PR, the changes in the updated file are not overwritten
[13:33:56] <sumanah> devesh: ok! So this is where you are going to advance in your understanding of git!
[13:34:33] <devesh> If that is something I can search, I can do that too
[13:34:53] <devesh> but i have burned my hands with incorrect git commands quite a few times
[13:34:58] <sumanah> (by the way, at this point, I advise that you give thanks that you are using a version control system that makes it a lot more possible to resolve this kind of conflict. Previous source control/version control systems were not nearly so capable of this)
[13:35:23] <devesh> I always thank git :)
[13:35:26] <sumanah> devesh: you could make a copy of the repository into a different directory, a test or temporary directory, on your computer, and try stuff there
[13:35:46] <sumanah> devesh: have you ever used "git rebase" before?
[13:36:17] <devesh> yes I have used git rebase -i HEAD~2, and squashed last 2 commits into one
[13:36:35] <devesh> then git push -f origin to push the squashed commit
[13:37:05] <sumanah> right
[13:37:36] <sumanah> https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request has a little more info about how to rebase a pull request so that it is up to date with git master on the canonical repo
[13:38:03] <devesh> let me go through that
[13:38:20] <sumanah> after you try to rebase, git will say "hey, conflict" and you will need to resolve the conflicts -- https://zulip.readthedocs.io/en/latest/git/troubleshooting.html#recover-from-a-git-rebase-failure may help you figure out how to do that
[13:39:07] <devesh> I do see that there is a BrownTruck bots who puts "needs rebase of merge" label to some of the PRs
[13:39:17] <devesh> I guess it's related to the link sumanah shared
[13:55:17] <cnx> hi devesh, you might also want to ``git pull --rebase master'' sometimes, although that does not save you from all conflicts
[13:57:50] <devesh> thanks cnx
[13:59:14] <cnx> you're welcome
[14:03:12] <devesh> Can I also merge an updated master branch to my feature branch, resolve the conflicts and push the commits
[14:03:23] <pradyunsg> devesh: yes.
[14:03:32] <devesh> It just adds a extra "merge remote-tracking master to blah" commit
[14:03:45] <devesh> but is an easier approach to rebase, are such commits fine in pip history?
[14:11:42] <cnx> devesh, fix me if I'm wrong I think at this point pip's log is no longer something one can read for leisure
[14:12:28] <devesh> cnx: "fix me" ?
[14:13:05] <devesh> Yes I don't see a standard for pip commits, apart from maybe not being more than 50 chars
[14:13:15] <devesh> *pip commi messages
[14:13:30] <devesh> *pip commit messages
[14:13:39] <cnx> I meant I'm not sure about the maintainers opinion but the log it's quite of, ehm, a mess
[14:14:08] <cnx> so if we can keep the blame meaningful that'd be
[14:14:27] <cnx> devesh, 50? TIL, thought it's 72
[14:16:19] <devesh> I was informed by uranusjr about it here: https://github.com/pypa/pip/pull/7899#issuecomment-603991908
[14:16:59] <pradyunsg> cnx, devesh: when in doubt, follow https://chris.beams.io/posts/git-commit/
[14:17:00] <pradyunsg> :)
[14:17:01] <devesh> Ohh, so 50 chars is summary, 72 chars wrapping of following commit message
[14:17:28] <pradyunsg> -> https://chris.beams.io/posts/git-commit/#seven-rules
[14:17:34] <pradyunsg> devesh: yep.
[14:18:45] <cnx> thanks, the explanations makes sense too
[14:18:50] <devesh> btw pradyunsg, since this is the release month, when do you generally stop accepting any new commits to master
[14:20:07] <cjc7373> I think current commit messages are truly a bit messy, maybe this format will be better, take a look at https://github.com/microsoft/terminal/commits/master
[14:22:14] <pradyunsg> devesh: It's generally for a few days (3-7?) prior to the first release of the cycle, and depending on the release manager, for a bit of time *after* the first release.
[14:23:29] <devesh> okay, I think you are the release manager, So do you post a message on every pr, saying no merging till release
[14:24:36] <cnx> cjc7373: the article (if you read it) explain carefully (imho) good practises for commit msg
[14:24:47] <pradyunsg> cjc7373: yea, we don't have a standard commit message format, it's fairly tricky to do that when you're not a company with employees -- where it's possible to establish *and* enforce strict rules for things like that; since they're the only folks working on the codebase.
[14:25:21] <cnx> i think it's more with time spend telling people to amend this squash that
[14:26:12] <cnx> 's been working with 2 of my class mates for a few months on a small-medium size project and every pr is a pain to enforce any kind of style
[14:26:15] <pradyunsg> cjc7373: I think most (not all) of the commit messages in pip are "good enough", even if not in the same format to make the history look pretty. :)
[14:27:18] <devesh> btw pradyunsg: I again got struck by the 'continuous-integration/travis-ci' check, which never completes
[14:27:41] <pradyunsg> cjc7373: and... the project you've linked to uses squash-merging, which, creates cleaner master branch histories (which is why they're used).
[14:27:56] <devesh> The correct one is 'continuous-integration/travis-ci/pr', which completes and you also can see Details link besides it, which doesn't show up here
[14:28:48] <pradyunsg> cnx: that too; a lot of this is opinion based, so I tend to think that as long as it's not affecting the workflow; it's fine to leave it as is.
[14:31:02] <cjc7373> cnx that's ture, complex workflow needs more time for new users to start
[14:31:57] <devesh> both https://github.com/pypa/pip/pull/7938 and https://github.com/pypa/pip/pull/7929 are affected, both stuck on "1 expected checks"
[14:32:17] <devesh> Only fix I know is close/reopen the PR, and the check gets triggered correctly
[14:32:41] <cnx> wait 7929 is mine
[14:33:33] <cnx> ugh travis, they got really weird lately
[14:33:47] <devesh> here and here are the fixes, https://travis-ci.community/t/known-issue-travis-ci-reports-expected-waiting-for-status-to-be-reported-on-the-github-status-api-but-the-status-never-arrives/1154
[14:33:49] <pradyunsg> devesh: re messages on PRs: Occasionally, yes. There might be some PRs that the release will be blocked on (release blockers), some others would get a nudge to complete by a cut-off date to be included in pip 20.1 and so on. All of this is basically determined based on judgment of the release manager.
[14:33:55] <devesh> and https://github.com/travis-ci/travis-ci/issues/10204
[14:34:13] <devesh> Could you make the necessary changes to the repo acc to this
[14:34:45] <devesh> pradyunsg: re:re messages on PR, Yes you will label the PR's accordingly
[14:36:43] <devesh> the travis issue says that ("continuous-integration/travis-ci" is the Status API event which is deprecated)
[14:46:07] <devesh> and I reopened and closed the PR to fix the expected check issue
[15:01:36] <cnx> heading to bed now, good night everyone
[15:03:06] <devesh> night cnx!
[15:03:07] <pradyunsg> devesh: re Travis CI: not really sure what to do here. :/
[15:03:31] <devesh> Did you look at the links I shared? https://github.com/travis-ci/travis-ci/issues/10204 and https://travis-ci.community/t/known-issue-travis-ci-reports-expected-waiting-for-status-to-be-reported-on-the-github-status-api-but-the-status-never-arrives/1154
[15:03:40] <devesh> They outline the fix pradyunsg
[15:04:04] <devesh> has to do with branch settings
[15:04:19] <pradyunsg> devesh: those newer tasks never ran on pip; so they don't show up in the "required checks page".
[15:04:44] <pradyunsg> (basically, there's no "Travis CI - Pull Request" check anywhere)
[15:05:12] <devesh> It says to find it in the "Branch Protection Settings" page
[15:06:17] <pradyunsg> devesh: I looked. I've spent ~15 minutes investigating the situation already. :)
[15:06:49] <pradyunsg> EWDurbin: do you happen to know if transitioning pip to travis-ci.com would affect pip's use of the "bigger pool of workers" that pypa has alloted to it?
[15:07:13] <pradyunsg> ^ that is, if I can figure out how to transition us to travis-ci.com.
[15:08:06] <devesh> Aah pradyunsg: so no such thing at https://github.com/pypa/pip/settings/branches :(
[15:08:23] <devesh> So whenever this issue rears up, we just close and reopen the pr
[15:08:30] <pradyunsg> devesh: that link is only accessible to those with the "Admin" bit for the repository.
[15:08:42] <EWDurbin> pradyunsg: i believe it would, subscription for the PyPA org on travis indicates 5 concurrent jobs, i can't find any information on travis-ci.org anymore about the bump in concurrent workers there. afaict we still have it but it's not displayed anywhere...
[15:08:43] <devesh> ohh, I thought you were the admin
[15:09:17] <devesh> I guess that whoever is the admin pradyunsg can try it out
[15:10:01] <pradyunsg> devesh: I am an admin; but the relevant check isn't there. (see my message from ~5 minutes back)
[15:11:11] <devesh> Aah okay, got it pradyunsg
[15:11:22] <pradyunsg> If anyone can find docs on how to transition a repo from travis-ci.org to travis-ci.com, that'd be great! I can't really figure out where Travis CI has documented it; if they have.
[15:11:43] <EWDurbin> pradyunsg: last i checked that was all a giant mess still...
[15:11:59] <pradyunsg> EWDurbin: :(
[15:12:06] <EWDurbin> the docs they published originally alluded to future information... and no future info came.
[15:13:04] <pradyunsg> Looks like newly created projects show up on travis-ci.com dorectly, so there's no way for me to even experiment and figure it out. :(
[15:15:01] <devesh> So this didn't help? https://docs.travis-ci.com/user/migrate/open-source-repository-migration
[15:15:19] <pradyunsg> devesh: yes!
[15:18:10] <EWDurbin> oh hey
[15:18:20] <EWDurbin> i mean it looks like the migration tool actually works as documented now
[15:18:34] <devesh> neither this? https://docs.travis-ci.com/user/migrate/open-source-repository-migration
[15:18:50] <devesh> Sorry this: https://docs.travis-ci.com/user/migrate/open-source-on-travis-ci-com/
[15:21:12] <pradyunsg> Looks like our options are: stick with the intermittently failing setup or opt into a beta (which may fail intermittently). \o/
[15:21:24] <pradyunsg> lol
[15:21:48] <EWDurbin> what's the issue?
[15:22:30] <pradyunsg> EWDurbin: Travis CI seems to be flaky in reporting back the status of PRs (see https://github.com/pypa/pip/pull/7929 for example)
[15:22:47] <EWDurbin> oh yeah, lol that's always an issue once in a while for warehouse too
[15:23:23] <devesh> Hi pradyunsg: There was a commit pushed to that pr, so the issue is not there anymore :(
[15:24:00] <pradyunsg> devesh: I linked to a diff PR that still has that.
[15:24:06] <pradyunsg> *that issue
[15:24:06] <toad_polo> I think that's an ongoing issue.
[15:24:11] <pradyunsg> toad_polo: yea.
[15:24:22] <pradyunsg> https://travis-ci.community/t/1154
[15:24:25] <toad_polo> We haven't gotten a PR status update on dateutil in days.
[15:24:50] <toad_polo> https://travis-ci.community/t/github-status-not-posted-on-commits-on-repositories-using-legacy-service-integration/7798
[15:25:20] <pradyunsg> (whoops, wrong link from me)
[15:26:08] <pradyunsg> https://travis-ci.community/c/product/14 <- whole bunch of folks reporting similar issues on their Forum.
[15:26:38] <toad_polo> I really hate Github Checks.
[15:26:53] <toad_polo> I liked the days when there were like 3 little status hooks on the main page, grouped by provider.
[15:27:05] <toad_polo> Now it's 40 noisy things crammed into a tiny box.
[15:27:21] <pradyunsg> https://travis-ci.community/t/7025/2 <- looks like a workaround.
[15:28:13] <pradyunsg> toad_polo: I agree!
[15:29:05] <pradyunsg> At some point, Azure Pipelines also started reporting *all* stages of a build, instead of just the overall jobs.
[15:30:05] <devesh> same thing as opening and closing a pr, or restarting a pc when nothing works , but with travis ci :)
[15:30:06] <pradyunsg> So, instead of just "MacOS, Linux, Windows", we end up with `OS matrix` x `tasks matrix` jobs from Azure.
[15:30:24] <pradyunsg> s/jobs/check/
[15:31:26] <pradyunsg> devesh: I now see, what you meant about "There was a commit pushed to that pr, so the issue is not there anymore".
[15:31:43] <devesh> pradyunsg :)
[15:33:48] <sumanah> techalchemy: I am cheering for you from my sofa ["Yay Dan! Go Dan!"] and just wanted to let you know.
[15:33:59] <devesh> And apologies for the aside pradyunsg, but the PR I was asking about and resolving merge conflicted, that was fixes: https://github.com/pypa/pip/pull/7938 . Please take a look whenever you can :)
[15:34:08] <techalchemy> sumanah, thanks, literally no idea what the hell is going on with azure tests
[15:34:16] <techalchemy> they seem to just...not run at all
[15:35:21] <sumanah> techalchemy: OK. I know you were working on that well into last night
[15:35:58] <sumanah> techalchemy: I could sort of put out a Bat-Signal on social media and ask for help -- that would be easier if you wrote out a bug report about what's going wrong
[15:36:10] <techalchemy> i dont even know really
[15:36:22] <techalchemy> [gw0] Python 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 23:03:10) [MSC v.1916 64 bit (AMD64)]
[15:36:30] <sumanah> Am listening
[15:36:32] <techalchemy> it just hangs here
[15:36:40] <techalchemy> not even sure if it's running or not
[15:37:03] <pradyunsg> techalchemy: link?\
[15:37:16] <devesh> yay thanks pradyunsg!
[15:37:30] <pradyunsg> devesh: :)
[15:37:40] <sumanah> ok. So you're not sure whether the job is even running, and (I am guessing) there's no dashboard or profiling or, like, the equivalent of ps -aux that you could run from a different login?
[15:38:08] <sumanah> pradyunsg: I'm pretty sure the failures are linked from https://github.com/pypa/pipenv/pull/4169 ?
[15:38:17] <sumanah> yeah I think https://github.com/pypa/pipenv/pull/4169/checks?check_run_id=550967732
[15:38:40] <pradyunsg> sumanah: yep! thanks! ^>^
[15:38:41] <sumanah> so https://dev.azure.com/pypa/pipenv/_build/results?buildId=21006&view=results
[15:39:22] <techalchemy> i thought they were just slow on windows, tried to add a ramdisk or whatever
[15:39:28] <techalchemy> but now i'm wondering if its something else
[15:39:33] <techalchemy> trying to spin up a windows vm
[15:39:55] <sumanah> So according to https://dev.azure.com/pypa/pipenv zero builds have succeeded in the past 30 days
[15:40:26] <techalchemy> yeah they didn't run in the first place
[15:41:10] <sumanah> right ... I see the line you just copied in https://dev.azure.com/pypa/pipenv/_build/results?buildId=21032&view=logs&j=2d4cb656-6149-5a33-f8b2-fd60a79c32e2
[15:42:07] <pradyunsg> techalchemy: I'm looking at https://dev.azure.com/pypa/pipenv/_build/results?buildId=21006&view=logs&j=2d4cb656-6149-5a33-f8b2-fd60a79c32e2&t=2e523d95-547d-5d21-14f5-e0266d0f4160 -- I guess running pytest with --verbose might show something useful?
[15:42:17] <techalchemy> its running with verbose
[15:42:28] <pradyunsg> oh lol
[15:42:44] <sumanah> and do we have logs to compare to, from anytime in the past that these pipelines ran successfully?
[15:42:54] <techalchemy> azure only saves 30 days of stuff
[15:43:15] <sumanah> hmmm... but maybe someone pasted some logs into a GitHub issue at some point?
[15:43:17] <sumanah> also, techalchemy, please feel free to tell me to zip my lips if I am being unhelpful
[15:43:25] <sumanah> I will do some ferreting around in the issues
[15:43:32] <techalchemy> i have literally 0 clue so far so anything helps
[15:43:37] <pradyunsg> https://dev.azure.com/pypa/pipenv/_pipeline/analytics/stageawareoutcome?definitionId=16&contextType=build <- Azure doesn't have a single passed test run.
[15:44:29] <pradyunsg> Wait no! I was wrong.
[15:44:54] <devesh> so the subfolder .azure_pipelines defines all the settings both in pip and pipenv
[15:45:06] <pradyunsg> There's a passing test run on 1/10/2020.
[15:45:18] <techalchemy> https://dev.azure.com/pypa/pipenv/_build/results?buildId=12109&view=logs&j=30daba86-a270-5904-a1ce-755cec2afc24&t=f762a2a6-f41f-596f-ef27-509e48e2c023
[15:45:21] <pradyunsg> Everything since has failed.
[15:45:24] <techalchemy> can you guys see this
[15:45:44] <pradyunsg> techalchemy: yep.
[15:45:53] <sumanah> Yes, I can see that
[15:46:07] <techalchemy> so i think tests may just run for more than an hour?
[15:46:11] <techalchemy> wtf
[15:46:16] <techalchemy> how is windows _that_ slow
[15:46:32] <sumanah> so that is from 2019-09-06
[15:46:56] <techalchemy> right, and it was taking ~55 mins almost
[15:47:00] <pradyunsg> techalchemy: there is supposed to be output, when the tests are running. I don't see it in the failing tests. Or am I missing something? :/
[15:47:10] <techalchemy> i mean, i thought there would be output yes
[15:47:18] <techalchemy> i'm highly confused about the lack of output
[15:47:41] <pradyunsg> https://dev.azure.com/pypa/pipenv/_pipeline/analytics/stageawareoutcome?definitionId=16&contextType=build -- change the view to 180 days from 14 days; there's information about when tests fail and all that.
[15:48:44] <techalchemy> maybe i can just split them up a bit further
[15:48:48] <sumanah> So this may be an obvious question, but: what changed between 2019-09-06 and the next run? Both within the codebase, and possibly on the Azure service itself?
[15:48:48] <pradyunsg> It seems like something changed between 10th Jan and 12th Jan, that broke pipenv's CI.
[15:49:12] <pradyunsg> (based on the analytics view above)
[15:49:18] <sumanah> oh I mean after Jan 10th
[15:49:34] <pradyunsg> (idk if sumanah or techalchemy can see that link)
[15:49:55] <sumanah> https://dev.azure.com/pypa/pipenv/_pipeline/analytics/stageawareoutcome?definitionId=16&contextType=build the "Pipeline failure report"? yes I can
[15:49:58] <devesh> that's a public link pradyunsg, even I can see that
[15:49:59] <techalchemy> i love that steep drop
[15:50:22] <techalchemy> that's like a covid19 graph pradyunsg
[15:50:30] <techalchemy> but upside down
[15:50:33] <pradyunsg> oky, that's good to know devesh, sumanah, techalchemy
[15:50:45] <sumanah> we gotta .... sharpen the curve? ;-)
[15:51:51] <pradyunsg> Imma head for dinner now. Be back in (hopefully) 45 minutes; maybe more.
[15:52:47] <sumanah> :-)
[15:52:54] <techalchemy> no changes to tests in like a year
[15:53:03] <techalchemy> er, azure files anyway
[15:53:35] <sumanah> techalchemy: is there something on Azure that is the equivalent of "make clean" or "rebuild all the environments/machines" that could be run? maybe there's a corrupt artifact somewhere
[15:53:48] <techalchemy> that sounds familiar
[15:54:49] <sumanah> ok. So: I see https://dev.azure.com/pypa/pipenv/_build/results?buildId=21032&view=results says that various things got cut off because they ran longer than the max of 60 minutes
[15:55:39] <sumanah> https://docs.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=yaml#timeouts says we can get "For 360 minutes (6 hours) on Microsoft-hosted agents with a public project and public repository"
[15:56:31] <sumanah> or "60 minutes on Microsoft-hosted agents with a private project or private repository (unless additional capacity is paid for)"
[15:56:51] <techalchemy> yeah so i think tests are actually running
[15:56:57] <techalchemy> just getting killed
[15:57:14] <sumanah> this is a public project & public repo. And I presume this is an MS-hosted agent. So I think the next step techalchemy might be for you to talk to support and tell them: this is a public project and repo, please up the allowance?
[15:57:14] <techalchemy> something must have made test runs take longer
[15:58:32] <sumanah> techalchemy: I suggest you look at the support page https://azure.microsoft.com/en-us/support/devops/?ol=0&oi=46012634-38f1-4cf5-a8fb-bc988fb8cc00&on=pypa and start looking at the ticket filing or something... I will poke around and see if there's a shortcut
[15:59:05] <techalchemy> thx, i'll just split up the tests real quick actually it will be faster than support i think
[15:59:09] <travis-ci> pypa/pip#15389 (master - 43f82c2 : Pradyun Gedam): The build passed.
[15:59:09] <travis-ci> Change view : https://github.com/pypa/pip/compare/7b02273f3e40...43f82c27f5f5
[15:59:09] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/669756450
[15:59:09] <sumanah> ah ok
[16:00:25] <toad_polo> pradyunsg: Did you try that workaround?
[16:00:50] <toad_polo> Did it require you to use the github checks version of Travis?
[16:02:03] <sumanah> and techalchemy please also ensure that you've set the timeout to zero https://github.com/MicrosoftDocs/vsts-docs/issues/4342
[16:02:44] <techalchemy> i dont even have a tmieout set
[16:03:20] <devesh> Atleast for mac osx python3.6, run-tests.sh is not working
[16:03:22] <sumanah> Hmmmm. I wonder, if you explicitly set the timeout to zero, whether that would help
[16:03:32] <devesh> Fails on this line https://github.com/pypa/pipenv/blob/master/run-tests.sh#L21
[16:04:11] <devesh> readlink: illegal option -- f , and the exit code is 1
[16:04:48] <sumanah> Azure also complains about running the tests for Python 3.6 on Mac OS X https://dev.azure.com/pypa/pipenv/_build/results?buildId=21032&view=logs&j=3e4210e3-70c3-5653-5018-f4b76c954b88&t=f00af58b-35cb-5e86-24b4-ae17f02c4fc7&l=52
[16:04:49] <devesh> similar to what I saw in https://dev.azure.com/pypa/pipenv/_build/results?buildId=21032&view=results under TestMacOS Python36 - Run integratin tests section
[16:05:11] <sumanah> devesh: you wanna take a look at that while Dan is working on the Windows stuff?
[16:05:15] <devesh> I have OSX 10.15.4 thought, OSX Catalina
[16:05:33] <devesh> sumanah: Can that be a reason, it's just a hunch from my end
[16:06:49] <sumanah> devesh: so we know that Azure is failing several runs on Windows and one run on Mac OS X, as you can see https://dev.azure.com/pypa/pipenv/_build/results?buildId=21032&view=results . So I'm suggesting that you try diving in and investigating the OS X problem
[16:07:11] <devesh> Aah okay, sure sumanah, let me try that
[16:07:21] <techalchemy> devesh, we don't run that file btw
[16:07:32] <techalchemy> interesting that it is broken though
[16:07:33] <techalchemy> lol
[16:08:02] <techalchemy> OSX has been passing ok for the most part
[16:08:29] <devesh> Okay, it was mentioned as an option in CONTRIBUTING.md, hence I tried it
[16:10:01] <devesh> The docker compose had that too: https://github.com/pypa/pipenv/blob/master/docker-compose.yml
[16:10:24] <toad_polo> pradyunsg: That workaround didn't work for me ☹︎
[16:11:46] <pradyunsg> toad_polo: I don't see the GitHub checks for Travis.
[16:11:56] <pradyunsg> (on pip's repo)
[16:11:57] <travis-ci> pypa/pip#15390 (master - 657cf25 : Paul Moore): The build passed.
[16:11:57] <travis-ci> Change view : https://github.com/pypa/pip/compare/43f82c27f5f5...657cf2515be0
[16:11:57] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/669762073
[16:13:36] <devesh> btw, I just saw this notice on one of the pipelines: https://devblogs.microsoft.com/devops/removing-older-images-in-azure-pipelines-hosted-pools/
[16:13:48] <devesh> Are we using any of these images in azure pipeline
[16:14:36] <pradyunsg> That's quite possible -- someone had to filed a PR to pip to prevent our Azure Pipelines from breaking due to that.
[16:16:35] <devesh> We are using macOS-10.13 at https://github.com/pypa/pipenv/blob/master/azure-pipelines.yml#L91
[17:00:14] <techalchemy> devesh, only on master
[17:00:19] <techalchemy> the branch in question is updated
[17:00:44] <devesh> what's the target branch for release?
[17:05:09] <devesh> Aah, is it feature/vendor-update techalchemy ?
[17:20:22] <travis-ci> pypa/packaging#882 (fix/287 - ddcab4c : Dustin Ingram): The build passed.
[17:20:22] <travis-ci> Change view : https://github.com/pypa/packaging/commit/ddcab4c25782
[17:20:22] <travis-ci> Build details : https://travis-ci.org/pypa/packaging/builds/669799964
[17:28:49] <sumanah> techalchemy: if you haven't had any lunch yet then I want to remind you to eat and drink
[17:30:05] <cooperlees> lol
[17:30:12] <cooperlees> sumanah always looking out for the dedicated
[17:30:43] <sumanah> He's been really focused!
[17:35:43] <techalchemy> ^ thanks sumanah i haven't had lunch yet
[17:39:10] <sumanah> devesh: yes, https://github.com/pypa/pipenv/pull/4169 has the branch
[17:41:29] <devesh> thanks sumanah
[17:49:56] <techalchemy> the next thing i'm doing after i get this working is figuring out how to delete azure pipelines
[18:06:16] <sumanah> techalchemy: :-) and did you find a moment to eat something?
[18:06:24] <techalchemy> no "|
[18:06:26] <techalchemy> :|
[18:07:00] <techalchemy> i have split up tests but can't figure out how to make azure respect my quotes
[18:17:20] <techalchemy> food now
[18:17:42] <pradyunsg> enjoy the meal. :)
[18:18:27] <pradyunsg> techalchemy: ^
[20:23:20] <sumanah> hey do any of you know who https://twitter.com/medullaskyline/status/1245445072398630912 is?
[20:24:44] <techalchemy> name looks familiar, happy to gather any feedback on stumbling blocks
[20:24:56] <pradyunsg> sumanah: not me.
[20:25:10] <sumanah> no prob :-)
[20:25:13] <techalchemy> 9/10 times i already agree but haven't thought of a clever solution
[20:26:27] <pradyunsg> I might've DOS'ed pip's CI by filing https://github.com/pypa/pip/pull/7954 too early.
[20:27:10] <sumanah> techalchemy: I see you have reached the stage where your commit messages are "why....."
[20:27:18] <techalchemy> lol
[20:27:28] <pradyunsg> lol
[20:27:46] <techalchemy> when troubleshooting azure i tend to give up on commit messages after the 100th attempt
[20:27:57] <pradyunsg> techalchemy: am back; happy to help if it's useful.
[20:28:05] <techalchemy> https://dev.azure.com/pypa/pipenv/_build/results?buildId=21059&view=logs&j=038113cc-d3a0-5868-8dca-9d29df33bd9c
[20:28:10] <techalchemy> i think CI is actually running now
[20:28:21] <techalchemy> just experimenting with splitting tests in half or whatever
[20:29:08] <pradyunsg> I am looking around at how other projects do PR checks (because of the discussion earlier today) and poetry's PR checks look clean: https://github.com/python-poetry/poetry/pull/2086
[20:30:01] <pradyunsg> ALAS, they also have snappy tests, and don't have additional "hey, have you tried XYZ" CI checks. :)
[20:34:52] <cooperlees> techalchemy: I went from azure to GitHub Actions as I found the debug path and plumbing up much easier / cleaner.
[20:35:27] <cooperlees> I don't know what you're doing but I recommend GitHub Actions simplicity. But I know you have a huge pipeline up there
[20:36:12] <techalchemy> cooperlees, yeah but it isn't _complicated_
[20:36:17] <techalchemy> it doesnt actually do much
[20:37:00] <cooperlees> I always got lost with the azure PyPA area and my pipelines ... when I used it on bandersnatch for MacOS and initial Windows testing.
[20:37:13] <cooperlees> But then actions came and I was like see ya!
[20:37:13] <sumanah> techalchemy: are you sure you don't want to try setting the timeout variable to zero?
[20:37:13] <sumanah> explicitly?
[20:37:56] <techalchemy> sumanah, i guess I can, I just don't really even know why it would take an hour on windows
[20:38:29] <sumanah> yeah, but since that's the world we're in .... https://docs.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=yaml#timeouts is the syntax as far as I can tell
[20:39:14] <sumanah> and then once you've done that, techalchemy, if things are still timing out at 60 min, then I can say, hey Microsoft, I think you need to switch a setting here, because this is an open source project that should get 360 min per run
[20:39:37] <techalchemy> i'll see if it still times out this run
[20:39:38] <sumanah> but there's a chance that the runs will be able to continue uninterrupted for, like, 70 min or whatever they need
[20:39:42] <techalchemy> this is blowing my mind
[20:44:28] <devesh> I have observed that it takes more time to write the unit test than to write the actual fix in pip repo :(
[20:47:18] <pradyunsg> devesh: I think that's true for a lot of projects, but yea, I'm sure pip's test suite doesn't make life easier. :(
[20:48:44] <devesh> Yes, there is everything present in the tests folder to create a test, but locating it is the hard part
[20:49:26] <pradyunsg> devesh: I understand. That's part of why "improve pip test helpers" is a GSoC project idea this year. :)
[20:50:03] <devesh> Yes, thanks to a potential GSoC'er I was able to fix a issue I took up finally as well :)
[20:50:13] <pradyunsg> :)
[20:50:55] <devesh> Have thanked them in the PR, least I could do
[20:52:51] <sumanah> devesh: multiple senior developers I have teamed up with all agree that writing tests is often harder than writing the feature that the test is checking.
[20:53:39] <sumanah> one went so far as to say: never try to be very clever writing the functional code. Be, at most, half as clever as you can. Because you will need to be TWICE as clever as that in order to test/fix it
[20:54:18] <devesh> True, because things can break in different ways, and you want to catch as many as you can in test
[20:54:30] <sumanah> yeah
[20:54:49] <cooperlees> devesh: That is in well tested code base!
[20:55:05] <cooperlees> And especially one as old as pip :)
[20:55:15] <devesh> People do try TDD to go over that test writing humo, but I have never used it myself to comment
[20:55:27] <pradyunsg> sumanah: "you need to twice as clever" -- I've also heard that in the context of debugging as well!
[20:55:32] <sumanah> right :-)
[20:55:33] <devesh> how old is the codebase cooperlees ?
[20:55:58] <pradyunsg> 11 years. :)
[20:55:59] <sumanah> pradyunsg: are you doing a bit better today, I hope?
[20:56:00] <techalchemy> debugging is at least 5x harder than writing tests
[20:56:12] <techalchemy> unless the test is hard
[20:56:19] <techalchemy> in which case you should refactor the code
[20:56:45] <pradyunsg> sumanah: yep. I've actually been productive for more than 4 hours today; which is more than I can say for most of the past 2 weeks.
[20:56:56] <sumanah> congrats pradyunsg!! [confetti, trumpets]
[20:57:05] <pradyunsg> :)
[20:57:12] <techalchemy> pradyunsg, nice work :D
[20:57:21] <sumanah> ok, so, it's nearly 5pm Eastern, so techalchemy I'm thinking you need REST. You were up so late last night! this is a hard problem and you need a fresh brain once in a while
[20:57:27] <devesh> yay pradyunsg, I actually saw you making more merges and pr's then before today :)
[20:57:37] <techalchemy> sumanah, I dont know if I'd call it *hard*
[20:57:38] <cooperlees> pradyunsg: What % of your life has pip existed?
[20:57:41] <techalchemy> lol
[20:57:44] <pradyunsg> lol
[20:57:47] <devesh> lol
[20:57:52] <pradyunsg> cooperlees: >50%
[20:57:57] <cooperlees> haha
[20:58:02] <techalchemy> that's amazing
[20:58:20] <devesh> Can I consider when I heard of pip to be % of my life lol ?
[20:59:01] <sumanah> techalchemy: how about "tedious and prone to tiny little errors"
[20:59:10] <techalchemy> ^^
[20:59:52] <pradyunsg> techalchemy: there's a GitHub workflow too now? ._.
[20:59:53] <sumanah> either way: just pretend that I did, like, a slides presentation here about the effect of sleep on attention to detail
[21:00:01] <techalchemy> pradyunsg, i mean
[21:00:12] <techalchemy> if it works
[21:00:17] <pradyunsg> ahahahaha
[21:00:20] <pradyunsg> I get it.
[21:00:47] <techalchemy> pradyunsg, i'm so sick of azure, this is like the 20th time i've made 60+ commits trying to fix azure
[21:01:10] <techalchemy> i gave up force-pushing amended commits even
[21:01:45] <pradyunsg> I think it deserves a separate PR just removing it from the codebase. Because there's going to be satisfaction clicking the green button knowing that the only thing it does, is remove AP.
[21:02:03] <pradyunsg> I mean, that's what I'd do lol.
[21:02:13] <techalchemy> it's also the 2nd time i just copy-pasted a github action from cooperlees
[21:02:25] <techalchemy> literally takes 3 seconds to set up
[21:02:35] <sumanah> cooperlees: (also, hi, hope you and yours are doing well)
[21:03:03] <cooperlees> sumanah: Sure am - Likewise. Lots of home time and a run / walk a day is my life of late as I am sure many of yours
[21:03:07] <cooperlees> Been good for bandersnatch
[21:03:13] <techalchemy> i also added a 0 minute timeout
[21:03:24] <cooperlees> techalchemy: Yay :D
[21:03:27] <sumanah> ok! let's see whether that helps.....
[21:03:29] <cooperlees> The push to PyPI is the best
[21:03:31] <techalchemy> cooperlees, i will be back on my bandersnatch pr if i ever release pipenv
[21:03:32] <techalchemy> lol
[21:03:39] <pradyunsg> techalchemy: now, we wait. XD
[21:03:42] <cooperlees> techalchemy: Does not hurt me :)
[21:03:51] <techalchemy> well it hurts me eventually :p
[21:04:01] <sumanah> cooperlees: I have been exercising a few times a week in my living room -- need to up that to 5 times a week at least.
[21:04:02] <cooperlees> I seem to have broken the PURGE call to PyPI ... Might look at that later
[21:04:03] <pradyunsg> techalchemy: for once, are you actually waiting for CI?
[21:04:14] <sumanah> ok, heading off for the night, catch y'all later.
[21:04:20] <cooperlees> sumanah: I'm more exercising for the getting out of the house with safe distances
[21:04:24] <sumanah> :-)
[21:04:31] <pradyunsg> have a good evening sumanah! o/
[21:04:37] <sumanah> \o
[21:04:38] <techalchemy> https://github.com/sarugaku/requirementslib <- the only issue i have with the github action for pushing to pypi so far is that despite 'releases' updating correctly, the tag on main repo page doesn't update
[21:05:13] <techalchemy> and yes pradyunsg i dont have windows anymore so i really need windows ci to run
[21:05:54] <cooperlees> I'm still blown away that bandersnatch runs mostly on windows now :D
[21:06:46] <pradyunsg> techalchemy: WAIT! YOU NO LONGER HAVE THAT HUMAN-KILLING WEAPON, THAT YOU CALLED A LAPTOP?
[21:08:04] <devesh> if a unit test added for a PR passes on mac and linux, but fails on windows, what might be wrong? Where I can look into
[21:08:46] <devesh> This is the pr in question, https://github.com/pypa/pip/pull/7955, the test might be wrong or the code logic might be too
[21:08:48] <pradyunsg> devesh: if it's paths, look at path separators? otherwise, it could be anything the OS-es differ on.
[21:09:45] <devesh> okay that's a good starting point, I haven never used windows for development, but I will check
[21:10:37] <pradyunsg> devesh: windows also has a case-sensitive file system by default.
[21:11:47] <pradyunsg> devesh: when you have a commit that has code from another contributor as well, it's a good idea to have multiple authors for that commit (https://help.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors)
[21:13:04] <devesh> Okay, I am using os package, so that should be taken care of I guess, and sys.path and os.getcwd() should behave similarly too
[21:14:09] <devesh> pradyunsg: re multiple authors: Does that mean using someone's idea or exact code? Because I guess ideas are anyways shared while doing PR's
[21:15:35] <techalchemy> pradyunsg, no i dont
[21:16:02] <techalchemy> https://www.lenovo.com/us/en/laptops/thinkpad/thinkpad-x/X1-Extreme-Gen-2/p/22TP2TXX1E2
[21:16:09] <pradyunsg> :(
[21:16:25] <techalchemy> my company provided the old one, i dont work there anymore
[21:16:53] <pradyunsg> OT: AMD's 4th gen laptop processors :O
[21:17:10] <pradyunsg> techalchemy: I remember that. That's why I was wondering.
[21:17:54] <techalchemy> are they nice? i was basically between this laptop and an xps but this one had better reviews
[21:18:37] <techalchemy> this one has 12 cores which is technically more than the old one
[21:18:51] <techalchemy> i did have to pay extra to match the 32gb ram i used to have
[21:21:22] <pradyunsg> I mean, the YouTube reviews for the 4th gen AMD laptops are titled "AMD just won laptops.", "AMD DID IT! This Ryzen 9 Notebook Is AMAZING" and "AMD's most important product ever - Ryzen 9 4900HS".
[21:22:51] <pradyunsg> So, I think they're pretty great and it's worth holding out for a bit until there's a few more laptops w/ these chips in them. Not like you can get them right now anyway, because there's someone is playing Plague Inc on the world map.
[21:33:28] <devesh> btw pradyunsg: Are you aware of any framework/tool which can simulate a windows python env on mac osx
[21:33:36] <devesh> and then I can try my pr there
[21:35:45] <techalchemy> devesh, there isn't really one
[21:35:54] <pradyunsg> devesh: no
[21:36:28] <devesh> okay, then I would revisit the core logic, and the python docs for windows and mac, and see where things went wrong
[21:36:34] <devesh> or maybe a pr reviewer can catch it
[21:37:16] <pradyunsg> or... drop a comment on the PR and wait for someone familiarity w/ Windows. :)
[21:38:58] <devesh> Aah, do we have such noble souls in the pip committers, working in the uncanny depth of windows
[21:39:09] <techalchemy> sadly
[21:39:23] <techalchemy> if you link me i might be able to tell you quickly
[21:39:32] <pradyunsg> lol
[21:40:04] <pradyunsg> urausjr and pfmoore use Windows daily; though I personally don't ping them until it's clear that I can every tim . :P
[21:40:21] <pradyunsg> *I can't figure it out -- basically don't ping them every time.
[21:40:25] <devesh> techalchemy, I think you have a lot on your plate already
[21:40:49] <devesh> But If you still want to look at it when the pipenv release storm passes, I can do it
[21:41:15] <devesh> here's the PR: https://github.com/pypa/pip/pull/7955
[21:41:23] <techalchemy> devesh, i'm trying to download a windows vm image atm
[21:41:28] <pradyunsg> lol
[21:41:34] <techalchemy> that will allegedly be awhile
[21:42:13] <devesh> Yes, btw I was able to fix the issue of run-tests.sh with readlink, we can use greadlink in macosx instead
[21:42:40] <devesh> If you want, I can dig deeper there and try to fix it, so folks can use it to run pipenv tests
[21:45:18] <techalchemy> devesh, you probably need to normalize the paths for comparison, e.g. os.getcwd() may not be exactly the same format as how it appears on sys.path on windows
[21:45:43] <devesh> os.path.normalize I guess?
[21:45:50] <devesh> Let me try
[21:45:57] <pradyunsg> It's normpath.
[21:46:38] <devesh> Ohh okay, so normalize paths on both LHS and RHS
[21:46:43] <techalchemy> devesh, https://github.com/pypa/pip/blob/master/src/pip/_internal/utils/misc.py#L302
[21:46:48] <pradyunsg> Yup
[21:47:18] <techalchemy> pip has a function to normalize paths already
[21:47:31] <techalchemy> it resolves symlinks etc
[21:47:53] <devesh> thanks techalchemy, your brain runs faster than chacha chaudhary (I hope pradyunsg gets that reference)
[21:48:20] <techalchemy> pradyunsg, isn't it like 5am
[21:48:29] <devesh> 3:18
[21:48:33] <pradyunsg> 3:18
[21:48:50] <pradyunsg> devesh: is also in the same timezone; and has a similarly messed up sleep cycle. XD
[21:49:01] <techalchemy> nice
[21:49:07] <techalchemy> and now is when you are productive
[21:49:10] <techalchemy> lol
[21:49:29] <devesh> that's due to wfh since past 3 weeks
[21:49:38] <techalchemy> fair
[21:50:27] <devesh> but a messed up cycle is more expected from college students like pradyunsg :D
[22:19:55] <devesh> hi techalchemy, thanks for the suggestion about normalizing paths
[22:20:05] <devesh> 2 of the 6 window checks passed :)
[22:20:18] <devesh> really appreciate it!
[22:20:45] <pradyunsg> wait, why not the rest?
[22:20:50] <pradyunsg> oh, they're still running.
[22:21:03] <pradyunsg> *sigh* 30 minute test suites.
[22:21:21] <devesh> yessir
[22:27:44] <devesh> What's the difference between Test Primary and Test Secondary for windows?
[22:31:39] <devesh> yay, all check passed, I can sleep in peace now :)
[22:31:51] <pradyunsg> devesh: wel..
[22:32:09] <pradyunsg> primary is tasks that need to pass for secondary to run. :)
[22:32:25] <devesh> that's pretty clear, thanks :)
[22:37:10] <travis-ci> pypa/pip#15406 (master - 4b159c5 : Pradyun Gedam): The build passed.
[22:37:10] <travis-ci> Change view : https://github.com/pypa/pip/compare/657cf2515be0...4b159c5420b0
[22:37:10] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/669908441
[23:18:47] <techalchemy> pradyunsg, https://dev.azure.com/pypa/pipenv/_build/results?buildId=21090&view=logs&j=401632ab-6b4e-5ac3-b762-e08148652d97
[23:18:49] <techalchemy> over 2 hours already