Forum Archive

(earlier discussion about / source version for pipista can be found here)

I've run into some bugs in Pythonista that I'm currently working on workarounds.

Here's the current (very alpha) version of pipista - with module installation support:

https://gist.github.com/4317095

You can install it and use it fine, as is, for the things that 1.0 did.

However, here's a list of a few bugs I've run into that it successfully patches:

• xmlrpclib is missing from Pythonista (known issue)
• ConfigParser is missing from Pythonista (new issue, to the best of my knowledge)
• distutils.util.get_platform( ) is broken in Pythonista. This is a new issue. My code temporarily patches it to sys.platform (the default value) to avoid it attempting to look up Makefiles and other build configuration headers which Pythonista doesn't have in place (lib/config/Makefile) even though it claims to be a 'posix' build. I can't permanently patch this one since it's baked into Pythonista.app itself.

Side bug: Running 'locals()' in the interpreter in Console view results in errors trying to generate repr strings for some of Pythonista's custom objects. You can still do locals().keys() and get to the objects in there, it might just break some things ... (see below)

New features:
Added the ability when using the pypi_install( ... ) method to automatically handle zip, .tgz, .tar.gz, and .tar files, decompress them in a temporary location, and locate the setup.py file necessary to configure the module installation.

In progress:
The current really big bug I'm trying to squash is that the exec statement, when used by distutils.core, seems to be doing something odd:

exec open(script_name, 'r').read() in g, l

This is supposed to execute the 'setup.py' python script in a separate global and local environment from the existing parent one - storing newly created global variables in 'g' and newly created local variables in 'l'.

However, any 'setup.py' script that gets run through there by disutils.core.run_setup( ) invariably breaks the first time it imports something and tries to reference it. Two good examples are the setup.py from 'versiontools' and from 'greenlet' (both are just test modules, not expecting them to function correctly when installed in Pythonista - well, not greenlet anyways).

'versiontools' throws:

>>> import pipista
>>> pipista.pypi_install('versiontools')
* Downloading: http://pypi.python.org/packages/source/v/versiontools/versiontools-1.9.1.tar.gz
Downloaded 19089 of 19089 bytes (100.00%)

* Saved to: versiontools-1.9.1.tar.gz
* setup.py found here: /private/var/mobile/Applications/25CC0752-0E40-4CD9-8C41-B059EC92A3C5/Documents/pypi-modules/.tmp/unpack/versiontools-1.9.1
* Compiling pure python modules ...
Traceback (most recent call last):
  File "", line 1, in 
  File "/var/mobile/Applications/25CC0752-0E40-4CD9-8C41-B059EC92A3C5/Documents/pipista.py", line 492, in pypi_install
    result = _py_build(setup_dir)
  File "/var/mobile/Applications/25CC0752-0E40-4CD9-8C41-B059EC92A3C5/Documents/pipista.py", line 445, in _py_build
    result = distutils.core.run_setup('setup.py', ['build_py', '--force'])
  File "/var/mobile/Applications/25CC0752-0E40-4CD9-8C41-B059EC92A3C5/Pythonista.app/pylib/distutils/core.py", line 219, in run_setup
    exec open(script_name, 'r').read() in g, l
  File "", line 22, in 
ImportError: No module named versiontools.versiontools_support

'greenlet' throws a similar complaint about 'no module named glob'

If you download and look at the source of each of these modules, the setup.py files in these instances are just running simple imports (and in the case of greenlet, it's attempting to import glob - a module that's standard in python) and then attempting to access the imported modules. Something weird is happening to exec where it's shoving these modules somewhere unexpected, but I'll keep working on it.

... And it's not just a simple bug, either, mind you - running this in console manually works as expected:

g, l = {}, {}
exec 'import glob\ntest_var = glob.__name__' in g, l

Something about the interaction between Pythonista and the distutils it comes with is causing this issue.

(Note: The pipista script works great on other versions of python and will happily download and install the pure python portion of PyPI modules. It's just these Pythonista idiosyncrasies I've got to iron out and then we'll be all set.)

Just thought I'd fill everyone in on the details in the meantime.

for some reason i get: global xmlrpclib is not defined
and quick question: how to you get your code in those yellow squares

@Dalorbi - If you use my pipista module, the first time you import it, it will create a new directory called "pypi-modules" where it will install these patches (ConfigParser.py, xmlrpclib.py, etc.)

So, if you want to use 'import xmlrpclib' in some other project, after pipista installs a copy of it, you have two options:

1.) 'import pipista' first. This automatically patches your sys.path variable to include the 'pypi-modules' directory. You should be able to do a 'import xmlrpclib' afterwards and it should succeed. (I made it work like this on purpose)

or

2.) 'import sys', then insert the 'pypi-modules' folder into the sys.path list. This will increase the number of locations Pythonista looks for python modules to include the ones that pipista installs.

As for the yellow squares, this forum allows for a certain amount of HTML. The yellow blocks are what you get when you do a <PRE>pre-formatted</PRE> block around your text.

So far, I've noticed that bold, italics, underline, unordered lists (UL / LI), links (A HREF), etc. all seem to work.

@pudquick I edited pipista significantly:

• Added automatic download of py_compile module.
• Downloaded modules can now be imported normally! This means that you can just do "import xmlrpclib" without first importing pipista or modifying sys.path.

The key to making downloaded modules importable but not visible to the editor was compiling them to .pyc files using py_compile first.

FYI, I probably broke something(s) while doing this and haven't tested much at all. Feel free to modify this.

Hope it helps!

https://gist.github.com/d515c286c93a4fd785ce

@C0deH4cker - The .pyc thing is a good trick to know! That solves the problem of individual .py files cluttering the editor window. And directories / complex modules already are hidden from the editor. I may have to reconsider storing them in the 'pypi-modules' directory now.

I might borrow that trick.

As for the bugs in exec( ), I'm still working on those.

Great stuff. Is there a simple module you guys have successfully installed using pipista? I keep running across modules which have dependencies are are looking for the python Makefile and failing. I'd like to help work on this, but a simple base case test would be great.

Spencer

Pipista 2.0 appears to be broken in iOS 7.1. An example: http://d.pr/i/jCl7

Would love to get it working again…