|
bitprophet posted:So, assuming SSH: you could do what m0nk3yz suggests, but I think Fabric is a much better idea; having a newbie wrestle with Paramiko and Pexpect doesn't sound like the best idea IMHO. He's going to need pexpect if it's telnet only, but I agree, check out Fabric as an alternative to hacking in paramiko. I meant to mention it, but my brain's become increasingly lossy P.S: Until Fabric gets the capability to pass in configuration files, and not to have to name them "fabfile.py" it's dead to me. I'd fork it, but I refuse to touch GPLed code :\ m0nk3yz fucked around with this message at 02:48 on Mar 6, 2009 |
# ? Mar 6, 2009 02:44 |
|
|
# ? Jun 24, 2024 07:18 |
|
m0nk3yz posted:He's going to need pexpect if it's telnet only, but I agree, check out Fabric as an alternative to hacking in paramiko. I meant to mention it, but my brain's become increasingly lossy As-is it can look for "~/.fabric" and use that as a (pretty naive) config file, loading up x=y config directives. I don't use that myself, though, and am rewriting Fabric to be way better behaved, which will include various command-line switches (including specifying config files). Out of curiosity, what exactly are you wanting to do with it that can't currently be done? If it's "using it as a module, e.g. import fabric.run and then call it", see below; otherwise, I'm not sure what you mean. I hope to be done with my rewrite of Fabric soonish (my typing is mostly back to normal now; would probably be done with the coding by now if not for a hand injury) and it should be a lot more open and easier to work with. Including being usable as a regular old Python module. As I mentioned to you on Twitter, depending on how things go I might try re-licensing it once all the old code is gone (I do prefer more permissive licenses than GPL), but it really depends; it's still technically not "my" project and we're working out the details of a possible handover.
|
# ? Mar 6, 2009 03:19 |
|
bitprophet posted:As-is it can look for "~/.fabric" and use that as a (pretty naive) config file, loading up x=y config directives. I don't use that myself, though, and am rewriting Fabric to be way better behaved, which will include various command-line switches (including specifying config files). I want to be able to do "fab -c <config> command" where config is any file I pass in (fabfile formatted, obviously). Also, concurrent execution (I have this working in my cluster SSH management tools) - looks like some of the latest changes get rid of some of my other nits. There's a handful of other things, but I can't recall them right now. I'd need to go back over my internal libraries to see (libraries which I have requested to be able to open source, MIT/BSD style)
|
# ? Mar 6, 2009 03:24 |
|
m0nk3yz posted:I want to be able to do "fab -c <config> command" where config is any file I pass in (fabfile formatted, obviously). Also, concurrent execution (I have this working in my cluster SSH management tools) - looks like some of the latest changes get rid of some of my other nits. Yea, that kind of -c option is the sort of thing I'm in the middle of adding. It won't even be strictly necessary, though, because you won't even need to use fab to run "Fabfile" like things -- they'll be regular old Python files. Fabric will become a library, with 'fab' being a convenient way to execute callables in what used to be a fabfile. (There may end up being some extra pieces of functionality only available when invoked via 'fab', of course, but only things that aren't possible otherwise) All other suggestions are welcome too -- my goal with the rewrite is to make it very well behaved, Pythonic, a good Unix citizen, all that jazz (none of which currently describe it, really). bitprophet fucked around with this message at 03:33 on Mar 6, 2009 |
# ? Mar 6, 2009 03:30 |
|
bitprophet posted:Yea, that kind of -c option is the sort of thing I'm in the middle of adding. It won't even be strictly necessary, though, because you won't even need to use fab to run "Fabfile" like things -- they'll be regular old Python files. Fabric will become a library, with 'fab' being a convenient way to execute callables in what used to be a fabfile. (There may end up being some extra pieces of functionality only available when invoked via 'fab', of course, but only things that aren't possible otherwise) +1000000 - I just have a bad itch for this very thing right now for a work project, which is why I'm pouting about it.
|
# ? Mar 6, 2009 04:03 |
|
I'll try to work faster (I really do want to get it done soon, lots of folks have been told about it and/or expressed interest, and I do have most of it worked out) You can see the current state of it here (note that the top level fabric.py is vestigial and there for my reference while I work on the fabric/ module). I just explicitly updated it with your "load fabfiley-like things" idea. I wasn't done with brainstorming the command line flags anyways, but anytime something is mentioned that makes me go "good idea!" I make sure to stick it in Off to bed now, no more Fabric posts from me tonight, promise...
|
# ? Mar 6, 2009 04:13 |
|
bitprophet posted:I'll try to work faster (I really do want to get it done soon, lots of folks have been told about it and/or expressed interest, and I do have most of it worked out) That does look better. Hooray! I can even contrib when/if you get it relicensed. Paver could use this too.
|
# ? Mar 6, 2009 04:19 |
|
Animosity posted:I think you want to check out the pycurses module Even better than curses is urwid. The python curses module doesn't offer what one would call a "pythonic" API by any stretch of the imagination. It's a pretty thin wrapper around the ncurses library. urwid, on the other hand, is a more object-oriented library with support for widgets. Widgets are a pretty useful abstraction that ncurses doesn't offer. urwid also supports multiple backends, so curses can use urwid, write out raw VT100 escape sequences, or even interface with apache to provide a web interface.
|
# ? Mar 6, 2009 04:41 |
|
Nice, that looks awesome.
|
# ? Mar 6, 2009 06:31 |
|
Can someone please explain to me WTF is going on here:code:
|
# ? Mar 6, 2009 13:13 |
|
bitprophet posted:Big, important question: is it literally telnet, or is it SSH? Yes indeed. It is telnet. I already have all of that written out with telnetlib, but need to work on capturing the data and parsing through it.
|
# ? Mar 6, 2009 16:25 |
|
Zombywuf posted:Can someone please explain to me WTF is going on here: code:
I assume you changed your text without re-testing it, so I'll take a guess at the problem/solution anyway. urllib can't encode Unicode, because it only handles bytes. You need to convert the unicode string, which is a sequence of code points, to a byte string, which is a sequence of bytes. code:
|
# ? Mar 6, 2009 19:13 |
|
Schatten posted:Yes indeed. It is telnet. I already have all of that written out with telnetlib, but need to work on capturing the data and parsing through it. Bummer. Then, I think m0nk3yz' suggestion of pexpect might be what you should look into. Haven't actually used it myself, though.
|
# ? Mar 6, 2009 19:21 |
|
Zombywuf posted:Can someone please explain to me WTF is going on here: I thought I was the only one there who understood python unicode
|
# ? Mar 6, 2009 21:23 |
|
Janin posted:
Is the forum written in python too? The loving unicode characters appeared when I previewed it, but then became double escaped in the thread. IT'S TWO THOUSAND AND loving NINE PEOPLE! UNICODE IS A SOLVED PROBLEM.
|
# ? Mar 6, 2009 21:49 |
|
Zombywuf posted:IT'S TWO THOUSAND AND loving NINE PEOPLE! UNICODE IS A SOLVED PROBLEM. Just like Soap!
|
# ? Mar 6, 2009 21:53 |
|
tef posted:Just like Soap! SOAP is only a solved problem if you are Sir Humphrey Appleby.
|
# ? Mar 6, 2009 22:07 |
|
Zombywuf posted:Is the forum written in python too? The loving unicode characters appeared when I previewed it, but then became double escaped in the thread. Not in PHP.
|
# ? Mar 6, 2009 22:29 |
|
A A 2 3 5 8 K posted:Not in PHP. Is anything solved in PHP? Also, anyone not using virtualenv, virtualenvwrapper and pip need to read up on 'em Right loving Now. I'm always the last one on the bandwagon, but holy crap do they make managing your Python libs way, way easier. Especially on systems with irritating Python/site-packages management (here's looking at you, OS X).
|
# ? Mar 6, 2009 22:40 |
|
Zombywuf posted:
Python handles Unicode almost perfectly. PHP, on the other hand, has made a clusterfuck of it. e: bitprophet posted:Is anything solved in PHP? quote:It cannot install from eggs. It only installs from source. (Maybe this will be changed sometime, but it’s low priority.) Despite all the hype pip receives, it fails to perform the two tasks I need a package manager to do. If all I had to worry about was pure-python tarballs installed on POSIX systems, there would be no need for any tool but "cp". TOO SCSI FOR MY CAT fucked around with this message at 23:08 on Mar 6, 2009 |
# ? Mar 6, 2009 23:02 |
|
Janin posted:Despite all the hype pip receives, it fails to perform the two tasks I need a package manager to do. If all I had to worry about was pure-python tarballs installed on POSIX systems, there would be no need for any tool but "cp". Fine, don't use pip, but you should still check out virtualenv/wrapper -- pip isn't at all required (easy_install works just fine with virtualenvs).
|
# ? Mar 7, 2009 01:36 |
|
Janin posted:Python handles Unicode almost perfectly. PHP, on the other hand, has made a clusterfuck of it. Eggs are an abortion I understand it's the "norm" for binary distributions, but I still hate it. I wonder if you could snag an egg, uncompress it and install it rather than install setuptools/easyinstall/etc and keep those damned zip files around. That and pip allows me to install directly from svn/hg - which is loving awesome.
|
# ? Mar 7, 2009 01:51 |
|
I just wish we'd get a cross platform apt-get for python to solve all the install problems.
|
# ? Mar 7, 2009 03:20 |
|
Yikes. Most platforms have an existing package system (for example dpkg, rpm and the tools built on top of them), and it's a pity to try and implement a system on top of it.
|
# ? Mar 7, 2009 03:33 |
|
tef posted:Yikes. In my understanding, the primary issue is that operating-system package managers are at odds with the distribution of programming libraries: an OS generally favors infrequent updates in order to preserve some semblance of stability, while libraries are updated frequently because they're often being worked on heavily, adding new features or fixing bugs. Because of this, the libraries found in e.g. APT or RPM are going to be pretty outdated most of the time, often older than many programmers want, who then turn to or create exterior distribution channels like RubyGems or PyPI/easy_install. This causes friction because obviously the OS's native packaging system is going to conflict at least a little (if not a lot, see Debian-vs-Gems) with something that's not designed to fit in with it. Personally, I've ended up where I install the bare minimum via the OS (so on Ubuntu/Debian, python and python-setuptools) and use the language "package manager" (easy_install, which is part of setuptools) to install the rest of the libs. (Except what I really do as of yesterday is make a virtualenv for whatever project I'm on, easy_install pip in it and then pip install the required stuff, or point pip at a requirements file) The only problem is that setuptools doesn't have a %#$! uninstall option (though I believe it can upgrade existing libraries) which is a bit of a pain. Virtualenv helps a lot with that, however, since it's easier to manage stuff when it's only a handful of libs per-environment instead of an entire system's worth. bitprophet fucked around with this message at 04:04 on Mar 7, 2009 |
# ? Mar 7, 2009 03:53 |
|
What bitprophet said - OS level package managers are a piss poor method of tracking programming language libraries/addons. They rev too slowly, some of them have relatively onerous requirements for inclusion (we hateses the debian), etc. The on problem though, is that for python, we have distutils, setuptools, whatever the frack zope uses, then pip, easy_install and so on. Setuptools is essentially unmaintained at this point, and has some nasty bugs and "setuptools"-isms that make it unpleasant as well. Also, lack of versioning, uninstall and so on. That, and none of these are built into python for a variety of reasons (too many damned conflicting requirements from too many people for on) but without something built in, I don't know how likely we are to have "one true way", which is not-so-cool. Tarek Ziade is the new distutils maintainer though, and I know he's got big plans - I think he's doing a bunch of planning for discussions at pycon around this very subject. m0nk3yz fucked around with this message at 04:33 on Mar 7, 2009 |
# ? Mar 7, 2009 04:31 |
|
Janin posted:Despite all the hype pip receives, it fails to perform the two tasks I need a package manager to do. If all I had to worry about was pure-python tarballs installed on POSIX systems, there would be no need for any tool but "cp". Yes, I really wanted to use pip, but the lack of Windows support turned me off. I wish it supported Windows not only for my current projects, but I want pip to spread far and wide, and not supporting Windows will hinder that.
|
# ? Mar 7, 2009 05:09 |
|
^^^ I, too, hope pip gets better Windows support. I loathe Windows personally, but it's important to reach out to you poor sods who are stuck there because ideally platform choice shouldn't prevent one from using awesome Python tools.m0nk3yz posted:The on problem though, is that for python, we have distutils, setuptools, whatever the frack zope uses, then pip, easy_install and so on. Setuptools is essentially unmaintained at this point, and has some nasty bugs and "setuptools"-isms that make it unpleasant as well. Also, lack of versioning, uninstall and so on. Well, it's actually distutils (which I thought was part of the stdlib?) => setuptools (which monkeypatches distutils and thus isn't actually 100% separate), of which easy_install is a component, => pip, which is a layer on top of setuptools and easy_install. No idea what Zope uses, I used to do some Zope and Plone and it's horribly unPythonic so I haven't touched it since. So it's a twisted family tree from distutils to pip, with now two layers addressing perceived deficiencies in the lower one(s), while also remaining somewhat backwards compatible (i.e. setuptools compatible distributions can be installed with pip, no problem). Ironically, RubyGems, while built from the ground up, is pretty lovely. Like many Ruby tools/libs, it works passably well in the specific use case the authors had in mind, and breaks in odd ways or just has stupid/silly behavior in every single edge case. in my ideal world APT would be slightly more user-friendly and not controlled by conservative GNU-heads, and every distro and language under the sun would use APT bitprophet fucked around with this message at 16:09 on Mar 7, 2009 |
# ? Mar 7, 2009 16:05 |
|
bitprophet posted:Fine, don't use pip, but you should still check out virtualenv/wrapper -- pip isn't at all required (easy_install works just fine with virtualenvs). What are the advantages of using virtualenv/wrapper, vs. just installing to a different prefix? I've seen lots of tutorials for them, and they sound interesting, but I don't know if it's a solution to a problem I haven't encountered (yet?). m0nk3yz posted:Eggs are an abortion I understand it's the "norm" for binary distributions, but I still hate it. I wonder if you could snag an egg, uncompress it and install it rather than install setuptools/easyinstall/etc and keep those damned zip files around. Of course you can unzip compressed eggs. The egg format doesn't mandate compression, just provides it as an optional distribution format. As long as Python can import it, it can be used, and as long as the egg-info directory exists, pkg_resources and all its goodies will work properly. setuptools is just a builder/installer. bitprophet posted:Well, it's actually distutils (which I thought was part of the stdlib?) => setuptools (which monkeypatches distutils and thus isn't actually 100% separate), of which easy_install is a component, => pip, which is a layer on top of setuptools and easy_install. No idea what Zope uses, I used to do some Zope and Plone and it's horribly unPythonic so I haven't touched it since. distutils is part of the stdlib. I thought pip entirely separate from setuptools? I hope it is, most of the technical criticism of setuptools is accurate.
|
# ? Mar 7, 2009 18:09 |
|
There will probably be an extremely simple solution to this. I'm using a module called Console, which is the Windows equivalent to Curses. The documentation/examples, however, aren't thorough, so hopefully someone here can help me understand why the following doesn't work: code:
Second of all, and the main problem, is that this program doesn't do anything. No errors, nothing. The code that has been commented out works fine. It's just the for loop I've got there now that won't work. Any advice?
|
# ? Mar 7, 2009 18:45 |
|
bitprophet posted:^ I guess I'm not seeing this. The only time rubygems fails on me is when installing a C extension where the linking libraries are not installed, like SQLite or MySQL or some such. I've seen it massively screwed up on Ubuntu, but the Ruby package on that is just messed up as Ubuntu wants you to install their (horribly outdated) libraries. I'd call Rubygems the best packaging system as it's flexible and easy to work with. CPAN would be great but... it's Perl and has the usability of Perl. I tried easy_install and pip. Pip wouldn't install mysql-python, easy_install worked but both I can't query what's been installed, what version or remove what's been installed.
|
# ? Mar 7, 2009 19:03 |
|
Janin posted:What are the advantages of using virtualenv/wrapper, vs. just installing to a different prefix? I've seen lots of tutorials for them, and they sound interesting, but I don't know if it's a solution to a problem I haven't encountered (yet?). No need to have superuser privs to install anything, easy working "virtual machines" so you can keep everything separate and at required versions, fast environment switching, and so on. You can also have multiple envs pointed at different python versions. It's awesome. Janin posted:Of course you can unzip compressed eggs. The egg format doesn't mandate compression, just provides it as an optional distribution format. As long as Python can import it, it can be used, and as long as the egg-info directory exists, pkg_resources and all its goodies will work properly. setuptools is just a builder/installer. I realize that; however eggs packaging, dependence on setuptools specific magic and so on is simply a mess. Not to mention, as bitprophet mentions, setuptools monkey patches distutils in... strange ways.
|
# ? Mar 7, 2009 19:08 |
|
NotShadowStar posted:I guess I'm not seeing this. The only time rubygems fails on me is when installing a C extension where the linking libraries are not installed, like SQLite or MySQL or some such. I've seen it massively screwed up on Ubuntu, but the Ruby package on that is just messed up as Ubuntu wants you to install their (horribly outdated) libraries. I'd call Rubygems the best packaging system as it's flexible and easy to work with. CPAN would be great but... it's Perl and has the usability of Perl. If linking libraries are missing, the python family of rubygems equivalents bomb out too. Python has the same problem with the "we want you to install packages from 1989, not 2009 thanx" ubuntu/debian has. Interesting that pip failed with mysql-python, I've had puke on a few setuptools-packaged things as well which I doubt is a pip issue so much as an issue with the way the package relies on setuptools. If you use pip, you end up having to supplement it with easy_install because of the widespread use of eggs/setuptools/easy_install.
|
# ? Mar 7, 2009 19:12 |
|
bitprophet posted:Well, it's actually distutils (which I thought was part of the stdlib?) => setuptools (which monkeypatches distutils and thus isn't actually 100% separate), of which easy_install is a component, => pip, which is a layer on top of setuptools and easy_install. No idea what Zope uses, I used to do some Zope and Plone and it's horribly unPythonic so I haven't touched it since. Distutils *is* part of the stdlib, and actually getting a lot of love right now. Also, pip does have issues with some setuptools-packaged packages but I can't remember which, because I blocked it out like an alien probing. See Tarek's blog for more info on plans: http://tarekziade.wordpress.com/
|
# ? Mar 7, 2009 19:17 |
|
NotShadowStar posted:I guess I'm not seeing this. The only time rubygems fails on me is when installing a C extension where the linking libraries are not installed, like SQLite or MySQL or some such. I've seen it massively screwed up on Ubuntu, but the Ruby package on that is just messed up as Ubuntu wants you to install their (horribly outdated) libraries. I'd call Rubygems the best packaging system as it's flexible and easy to work with. CPAN would be great but... it's Perl and has the usability of Perl. Gems isn't that horrible, I was exaggerating a bit, but it does strike me as not being well engineered; its default behavior of NOT pulling from remote repositories is simply maddening; it's slow as rear end to install ri/rdoc components; it doesn't script well, what with that "oh I have 6 different 'types' of $gemname version 1.2.3, please pick from this numbered menu" crap. And so forth. (Again, it seems to exhibit what seems like typical Ruby to me: works great in some, even many cases, but falls down a lot more than it really should and smacks of a "worksforme" attitude) quote:I tried easy_install and pip. Pip wouldn't install mysql-python, easy_install worked but both I can't query what's been installed, what version or remove what's been installed. Only time I've had problems with easy_install/pip and MySQLdb was when I forgot to have (on Ubuntu/Debian) libmysqlclient-dev installed; as long as the MySQL client lib source is available it's always worked fine for me. m0nk3yz posted:Distutils *is* part of the stdlib, and actually getting a lot of love right now. If distutils can get upgraded to support some of the common-sense stuff that setuptools/pip have bolten onto it (e.g. dependencies, requirements files, etc) that would be pretty awesome. bitprophet fucked around with this message at 00:07 on Mar 8, 2009 |
# ? Mar 8, 2009 00:03 |
|
bitprophet posted:If distutils can get upgraded to support some of the common-sense stuff that setuptools/pip have bolten onto it (e.g. dependencies, requirements files, etc) that would be pretty awesome. No kidding, as long as they avoid the bikeshed around dealing with OS-specific package manager functionality. I vaguely remember something about this on python-dev, and it was a trainwreck. Also, easy_fucking_uninstall for god's sake, as Zed Shaw would say.
|
# ? Mar 8, 2009 01:50 |
|
NotShadowStar posted:I tried easy_install and pip. Pip wouldn't install mysql-python, easy_install worked but both I can't query what's been installed, what version or remove what's been installed. Have you tried yolk? It provides some ways to get information about what you have installed and what has upgrades available.
|
# ? Mar 8, 2009 02:06 |
|
bitprophet posted:Gems isn't that horrible, I was exaggerating a bit, but it does strike me as not being well engineered; its default behavior of NOT pulling from remote repositories is simply maddening; it's slow as rear end to install ri/rdoc components; it doesn't script well, what with that "oh I have 6 different 'types' of $gemname version 1.2.3, please pick from this numbered menu" crap. And so forth. (Again, it seems to exhibit what seems like typical Ruby to me: works great in some, even many cases, but falls down a lot more than it really should and smacks of a "worksforme" attitude) I need to clear up some misconceptions. I dunno when you looked at Gem but it does all of what you're talking about. gem install clown_farts --version 6.0.0.6 -- --with_farts_dir = /home/bonky/lib/flippy RDoc/RI being slow is simply a result of RDoc/RI being slow. You can skip them --no-rdoc --no-ri
|
# ? Mar 8, 2009 02:30 |
|
I'm trying to implement the midpoint displacement algorithm to create a heightmap for a game that I am working on. I know that this code is probably incredibly stupid, but will it do what it is supposed to do? The maps it makes don't really look like examples that I see.code:
Vexed Morgan fucked around with this message at 12:36 on Mar 9, 2009 |
# ? Mar 9, 2009 11:07 |
|
|
# ? Jun 24, 2024 07:18 |
|
I am trying to wrap my head around how to make this more elegant. I can't think of anything:code:
code:
Edit: Also I'm currently using code:
ahobday fucked around with this message at 16:46 on Mar 9, 2009 |
# ? Mar 9, 2009 16:32 |