pmxbot IRC Log Viewer

[00:00:30] <techalchemy> ^ thanks

[05:14:19] <GPHemsley> techalchemy: I'm around if you need any info from me for pipenv #4263

[05:16:33] <techalchemy> thanks GPHemsley -- I just released for now since i dont think that will kill anyone and i didn't want to delay any more, I haven't even attempted to reproduce it yet

[05:17:10] <GPHemsley> it is gonna break things for me, I can tell you that

[05:17:46] <GPHemsley> (that's why I marked it as a potential blocker)

[05:18:05] <techalchemy> GPHemsley, the reasoning being that even though it most likely is broken as described, there is a workaround (i.e. if uninstalling doesn't remove something from `dev-packages`, it's always possible to remove it yourself)

[05:18:57] <GPHemsley> I run this command from CI, so it's a little difficult to remove from the pipfile.lock myself

[05:19:07] <techalchemy> release blockers typically are reserved for operationally breaking problems (e.g. the command explodes when you run it or deletes data irrecoverably) & has no workaround

[05:19:18] <techalchemy> I wouldn't advise locking in CI :/

[05:19:41] <GPHemsley> fair point

[05:20:13] <techalchemy> there are a lot of problems with how things are written to lockfiles that are fairly breaking for my own workflow

[05:22:10] <GPHemsley> so the problem that I was solving this way is the following: I have a dependency that (a particular version of cx-oracle) that fails installation if it does not find some external compile dependency; it is only required for a subset of scripts, and not the ones that CI is trying to run

[05:22:50] <GPHemsley> so to get CI to run, I simply run the uninstall command to remove it from the lock file so I can run sync without failing

[05:22:58] <techalchemy> ah

[05:23:31] <techalchemy> damn oracle

[05:24:11] <GPHemsley> there are side effects to running the uninstall with pipenv 2018 (--keep-outdated doesn't completely work) but it does succeed in doing what I intend most of the time

[05:24:30] <techalchemy> the sad reality is that lockfile manipulation is just not very good in pipenv

[05:24:48] <techalchemy> in theory you shouldn't have to touch your lockfile

[05:25:01] <techalchemy> but yeah, the theory is great etc

[05:26:48] <techalchemy> GPHemsley, to be honest, I'm not totally sure I thought about uninstall when i was implementing --keep-outdated

[05:27:24] <GPHemsley> to Oracle's credit, they fixed the issue with a later version - the problem is I've been depending on an old version of the package for compatibility reasons

[05:28:14] <GPHemsley> hmm... I'm not sure I checked whether removing --keep-outdated would work with pipenv 2020

[05:28:31] <GPHemsley> I added it to try to reduce the number of things installed

[05:28:43] <techalchemy> no idea, i mean, it makes sense

[05:29:31] <techalchemy> like, sometimes i really don't even want to manipulate a top level dependency, i just want to prune something specific from my lockfile (because i also manually retain dependencies that would be purged)

[05:30:00] <GPHemsley> I did briefly try to figure out what had changed to cause this change in behavior, but so much has happened between 2018 and 2020, so it was hard... and everything I looked at didn't appear to be the problem

[05:31:07] <GPHemsley> and speaking of pipfile problems, I did file this a little whole ago: https://github.com/pypa/pipfile/issues/125

[05:31:17] <GPHemsley> could potentially interfere with locking

[05:31:20] <techalchemy> i need to think of a good api to manage these more nuanced usages without overcomplicating things though... it's simple enough to install or uninstall things, but adding the ability to manipulate lockfile and/or pipfile directly is kinda opening up complexity a lot

[05:31:28] <techalchemy> oh pipfile... i am not even a maintainer on there

[05:31:47] <GPHemsley> (it did interfere while I was trying to manually update the Pipefile.lock)

[05:31:55] <techalchemy> pradyunsg recently added himself to it, i suspect he has plans to start using it in pip which means it could change in unpredictable ways

[05:32:41] <techalchemy> though currently only pipenv uses pipfiles so hopefully he talks to me first !

[05:34:03] <GPHemsley> hmm

[05:34:37] <techalchemy> Also I'm not even sure we use that to generate lockfiles anymore :|

[05:38:33] <GPHemsley> it is used to generate the hashes, at least

[05:38:37] <GPHemsley> which is how I got there

[05:42:06] <GPHemsley> incidentally, with pipenv 2020 now released, does that mean it's time to close #3369?

[05:43:08] <GPHemsley> also, what was the motivating factor for switching to date-based versions? that seems like it would preclude semver versioning

[05:56:10] <techalchemy> GPHemsley, it's a long story

[05:56:17] <techalchemy> but yeah it does preclude semver

[05:57:34] <techalchemy> semver isn't very reliable anyway, lots of releases break workflows that are critical for one reason or another and various people would want a major release for that -- api compatibility falls apart conceptually pretty fast if someone is using the internals of a CLI application for example

[05:58:02] <GPHemsley> I see

[05:58:40] <GPHemsley> though does seem kind of ironic for a tool used to track dependencies :-P

[05:58:50] <techalchemy> at the end of the day you have to read the changelog to see if you should expect a breakage anyhow so pretending the version number reflects that becomes disingenuous

[05:58:56] <techalchemy> calver is a valid versioning scheme

[05:59:23] <GPHemsley> heh, I thought calver was a person

[05:59:33] <techalchemy> calendar versioning

[05:59:40] <techalchemy> https://calver.org/

[05:59:57] <GPHemsley> yeah, I get that now :)

[06:01:11] <techalchemy> I was not in favor if including the specific date for what it's worth :p

[06:01:17] <techalchemy> of*

[06:03:07] <GPHemsley> that was gonna be my next argument... but wanted to read the spec first :)

[06:03:35] <techalchemy> GPHemsley, also, pipenv uninstall --dev <pkg> seems to work ok; if CI is a different OS you can also just add an environment marker or something... I'm not sure if anyone else is having the same experience but pipenv seems to run much faster

[06:03:56] <techalchemy> I'm not sure that was all due to intentional optimizations

[06:04:18] <GPHemsley> hmm, ok

[06:04:42] <GPHemsley> (un)fortunately, I'm off this week, so I'll give a look on Monday

[06:05:12] <GPHemsley> thanks for all your hard work, btw

[06:05:22] <GPHemsley> we will definitely benefit from the rest of the changes :)

[06:06:57] <techalchemy> np, and I'm sure i've mentioned this in 20-30 places by now but I am actually partly paid for this now so it will continue getting attention

[06:07:06] <techalchemy> just because your thing isn't fixed yet doesn't mean it won't be!

[06:07:38] <techalchemy> thanks for reporting and following up, it makes my life easier

[06:11:59] <GPHemsley> glad to hear it

[06:14:16] <GPHemsley> and pipenv makes my life easier, so I'm happy to pay that back and help where I can :)

[06:21:02] <techalchemy> :) appreciate it

[06:21:05] <techalchemy> i'm off to bed, thanks again!

[10:18:06] <travis-ci> pypa/pip#16517 (master - 03b11ee : Paul Moore): The build is still failing.

[10:18:07] <travis-ci> Change view : https://github.com/pypa/pip/compare/7c10d3ed3b8b...03b11eed8fe8

[10:18:07] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/692092545

[15:26:08] <GPHemsley> techalchemy: What do you make of my secondary observations? Do you think any of them need their own issues? https://github.com/pypa/pipenv/issues/4263#issuecomment-632473151

[15:26:41] <GPHemsley> I'm particularly concerned about versions not being pinned correctly

[15:27:18] <travis-ci> pypa/pip#16529 (master - 5fce05a : Pradyun Gedam): The build is still failing.

[15:27:18] <travis-ci> Change view : https://github.com/pypa/pip/compare/03b11eed8fe8...5fce05ae4d74

[15:27:18] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/692201794

[16:14:29] <sumanah> congrats techalchemy on the release! I put word out on distutils-sig, Twitter, discuss.python.org, and the tracking issue

[16:14:48] <techalchemy> oh wow thanks sumanah

[16:14:56] <techalchemy> GPHemsley, i responded on your issue btw

[16:15:11] <GPHemsley> techalchemy: I saw, thanks :)

[16:15:20] <techalchemy> sumanah, surprisingly the world is not on fire

[16:15:22] <GPHemsley> techalchemy: did you want me to file a separate issue on the version pinning thing?

[16:15:39] <sumanah> techalchemy: you did a kinda thorough beta and you had a lot of automated testing, so, yay!

[16:15:56] <sumanah> and I'm guessing there were a fair number of users who had been using git master

[16:16:07] <techalchemy> GPHemsley, yeah that one is concerning, although we definitely don't test the specific case you ran into it should still pin

[16:20:16] <GPHemsley> techalchemy: filed https://github.com/pypa/pipenv/issues/4278

[16:22:33] <techalchemy> thanks

[18:27:06] <travis-ci> pypa/packaging#964 (master - 59e1488 : sinoroc): The build passed.

[18:27:07] <travis-ci> Change view : https://github.com/pypa/packaging/compare/28a2e2bb88a8...59e14881910b

[18:27:07] <travis-ci> Build details : https://travis-ci.org/pypa/packaging/builds/692278513

[19:50:03] <sumanah> I'm most of the way through the pypa-dev Google Group sunsetting. Now I'm at the step:

[19:50:03] <sumanah> And then I would look through relevant documentation within PyPA

[19:50:03] <sumanah> repositories to see what needs updating (READMEs and so on pointing to

[19:50:03] <sumanah> the old list), and submit pull requests.

[19:57:25] <sumanah> most of the time this is the kind of teensy pull request that I make a Good First Job issue for instead of doing it myself

[19:57:28] <sumanah> today I am indulging

[19:57:31] <sumanah> and doing it myself

[20:52:03] <sumanah> ok, sometimes

[21:05:36] <sumanah> this is where my clumsy regex fingers are really causing me bleh

[21:27:25] <sumanah> if anyone wants to help me out, I am basically working my way through https://github.com/search?p=2&q=org%3Apypa+%22pypa-dev%22&type=Code

[21:39:47] <sumanah> ok, now I think it's just setuptools and Warehouse waiting, within github.com/pypa

[21:51:52] <sumanah> also, thank you Paul Ganssle for pointing me to https://github.com/pypa/setuptools/issues/2129#issuecomment-635266616 the incredibly obscure bug

[21:51:57] <sumanah> on social media

[22:29:46] <sumanah> ok, I'm calling myself done -- in some cases I've opened issues instead of making the PRs myself

[23:08:42] <travis-ci> pypa/pip#16542 (master - 1e67c3c : Paul Moore): The build passed.

[23:08:43] <travis-ci> Change view : https://github.com/pypa/pip/compare/d480e408388462815df59d796d33203d7821dd40...1e67c3cc201c3eaf7ac6927954729a01e4c28e45

[23:08:43] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/692358625

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Thursday the 28th of May, 2020