Shit said in #python


 
Ciar Main Page >> TTK's Home Page
 
More quotes: Alaric   Fuz   Sonic   Pie   Izzy   Danny   TTK   Shit Said in Python   Shit Said in Go   mst
 
 
Display quotes in order:     
 [1071] #continuous-integration
2017-12-12 15:57:33 <Remram> there are packages out there whose setup.py is insane, and errors out on PY3, or does something different, or
          doesn't handle egg_info
2017-12-12 15:57:55 <Remram> as long as we have those, package management on Python is going to be broken
2017-12-12 16:04:00 <ttkpy> CPAN solves this by shoving all newly contributed modules through CI in various environments (windows, linux,
          freebsd, various versions of the language, etc) .. when a module fails to build, that is noted on its MetaCPAN page
2017-12-12 16:04:32 <ttkpy> and users avoid using it until module authors fix their code (which might be in the code itself or in the
          installation blargh)
2017-12-12 16:04:58 <ttkpy> might python apply a similar solution to root out these naughty setup.py?
2017-12-12 16:06:38 <ttkpy> example of a naughty module's CPANtesters CI results grid:  http://matrix.cpantesters.org/?dist=Curses+1.36
2017-12-12 16:06:58 <dw> ttkpy: i posted this very thing to python-ideas many moons ago and it was shot down by the packaging guys as "too much work"
2017-12-12 16:07:18 <nedbat> dw, ttkpy: build it
2017-12-12 16:07:26 <runciter> who pays for the CI?
2017-12-12 16:07:54 <ttkpy> runciter - the CPANtesters are volunteers who provide their own hardware
2017-12-12 16:08:06 <dw> nedbat: i feel strongly disincentivized by every packaging-related interaction i've ever had
2017-12-12 16:08:19 <runciter> as a contributor to open source projects that use existing CI service's free tier, it can be a bummer because the
          CI services response times vary from good to terrible
2017-12-12 16:08:20 <nedbat> dw: it doesn't have to be part of pypi, does it?
2017-12-12 16:08:32 <runciter> ttkpy: how do you trust the CPANtesters?
2017-12-12 16:08:33 <dw> nedbat: a good solution does, yes
2017-12-12 16:08:49 <nedbat> dw: not at first?  And why does it need to be part of pypi?
2017-12-12 16:08:52 <ttkpy> runciter - through time and familiarity, so you won't get trust immediately upon launch
2017-12-12 16:09:22 <runciter> ttkpy: a lot of open source communities in python seem to be moving away from self-hosted solutions
2017-12-12 16:10:50 * ttkpy contemplates how he'd prioritize a CPANtesters-for-pypi project
2017-12-12 16:11:11 * ttkpy glances at the 70+ other projects he's neglecting
2017-12-12 16:14:58 <dw> nedbat: because the alternatiev is scraping pypi for already-released packages to discover failures.
2017-12-12 16:15:05 <dw> nedbat: it needs to happen as part of release
2017-12-12 16:15:28 <nedbat> dw: at first, you'd need to do it asynchronously. too much stuff would become unavailable if you gate releases on it.
2017-12-12 16:19:51 <dw> ttkpy, nedbat: https://mail.python.org/pipermail/python-ideas/2014-April/027705.html was the thread in question, it
          never got nearly as far as discussing pypi integration before devolving into arguing about how much work it'd be
2017-12-12 16:21:53 <ttkpy> thanks, dw
2017-12-12 16:22:29 <ttkpy> the success of CPANtesters implies it's not insurmountably difficult
2017-12-12 16:22:53 <ttkpy> the python community is far more vibrant and energized, so it should be easier to pull off
2017-12-12 16:24:24 <dw> code and technology are rarely the difficult parts of any project
     #python
 
 
 [1070] #windows
2017-11-03 13:00:27 <ChrisWarrick> windows doesn't do argument lists
2017-11-03 13:00:41 <ttkpy> wat
2017-11-03 13:01:11 <nanonyme> ChrisWarrick, oh, yeah, true, it goes through that stringification and might or might not get through in one piece
2017-11-03 13:01:50 <ChrisWarrick> ttkpy: windows deals with strings. Pythona's subprocess module takes those lists and stringifies them
          according to some rules. Then the subprocess unstringifies it according to some other rules.
2017-11-03 13:06:22 <nanonyme> ttkpy, if you want to dive into the horribleness that is Windows, https://github.com/python/cpython/blob/master/Lib/subprocess.py#L426
2017-11-03 13:07:13 <nanonyme> ttkpy, good luck trying to get your quotes intact through that. There's no quote escaping in Windows
2017-11-03 13:09:38 <nanonyme> ttkpy, what you usually do in Windows is you write a file and execute that.
2017-11-03 13:10:13 <nanonyme> Trying to do anything complex through command arguments is pure lunacy
2017-11-03 13:12:19 <ttkpy> nanonyme - I see.  Thank you.
     #python
 
 
 [1068] #windows
2014-04-29 16:38:44 <The_NetZ> very interesting. I come from a modest ruby bacground, but the fact that it sucks so bad on windows is discouraging, at least the latest versions.  How well does current python (3.x) run on windows?
2014-04-29 16:39:25 <ssbr_worklappy> The_NetZ: it performs adequately.
2014-04-29 16:40:20 <The_NetZ> ssbr_worklappy: and this is as a raw windows executable, not via cygwin or the like?
2014-04-29 16:41:10 <ssbr_worklappy> The_NetZ: of course!
2014-04-29 16:41:17 <ssbr_worklappy> The_NetZ: just be sure to install the 32bit one. :)
2014-04-29 16:42:32 <The_NetZ> ssbr_worklappy: is that so...  I realize that 32bit executables can run on 64bit systems, but in most cases 64bit executables are the default, but you mean in this case 32bit python is preferable to 64bit?
2014-04-29 16:43:07 <ssbr_worklappy> The_NetZ: most people use 32 bit python for windows, which means most third party libraries are built for 32 bit python.  It is a pain to get 64 bit libraries.
     #python
 
 
 [1040] #windows
2014-01-08 12:01:46 <cwillu_at_work> Enich, look into sqlalchemy
2014-01-08 12:01:50 <cwillu_at_work> oh, windows
2014-01-08 12:01:51 <cwillu_at_work> blech
     #python
 
 
 [1023] #windows
2013-11-12 13:21:00 <Jerub> actually, oursql sucks if you're on windows becasue i have no idea how to build it on that platform and there's a bunch of hard to fix bugs.
     #python
 
 
 [1022] #windows
2013-11-11 11:04:50 <mlt-> How can I use multiprocessing on windows in embedded python? As there is no fork() on that platform, multiprocessing pool fires up another instance of host application instead of python interpreter only. Is there an easy solution?
     #python
 
 
 [1019] #windows
2013-10-23 20:52:23 <ssbr> dw: my experience with windows is one where select magically doesn't work on pipes
     #python
 
 
 [1007] #windows
2013-10-11 18:20:04 <dunpeal> just wanted to say thanks, we're seeing a large performance degradation due to process spawning on Windows, and that's apparently it.
     #python
 
 
 [1006] #windows
2013-10-10 15:31:41 <kevlarman> Jerub: just do what i do: pretend no one runs windows servers and then act surprised when someone tries to do it :P
     #python
 
 
 [1005] #windows
2013-10-10 13:45:26 <ttback> Vivekananda_: a lot of stuffs are special on windows with python
2013-10-10 13:45:31 <ttback> Vivekananda_: i'm happy to not have to deal with that
     #python
 
 
 [1004] #windows
2013-10-09 12:08:39 <Remram> why aren't os.readlink() and os.symlink() available on Windows?
     #python
 
 
 [1003] #windows
2013-10-08 13:46:23 <eciv> in windows, why does os.path.join('dir','name') return dir\\name and not dir\name?
     #python
 
 
 [1002] #windows
2013-10-04 15:26:22 <noob101> Tritium, what is a daemons.
2013-10-04 15:26:40 <[Tritium]> noob101: they are called services on windows
     #python
 
 
 [1001] #windows
2013-10-04 10:50:40 <[Tritium]> gtk look horrid on windows </opinion>
     #python
 
 
 
 
    Ciar Main Page >> TTK's Home Page