Plone 4.3.3上带有粘贴的“ IOError：找不到鸡蛋信息目录”

Question

The error occurs also when using zopeskel in Plone 4.3.3. This seem to be slightly different from this question . Under Plone 4.3.2 there is no error.

$ ../bin/paster create plone_basic
Selected and implied templates:
  PasteScript#basic_package  A basic setuptools-enabled package

Variables:
  egg:      plone_basic
  package:  plone_basic
  project:  plone_basic
Enter version (Version (like 0.1)) ['']:
Enter description (One-line description of the package) ['']:
Enter long_description (Multi-line description (in reST)) ['']:
Enter keywords (Space-separated keywords/tags) ['']:
Enter author (Author name) ['']:
Enter author_email (Author email) ['']:
Enter url (URL of homepage) ['']:
Enter license_name (License name) ['']:
Enter zip_safe (True/False: if the package can be distributed as a .zip file) [False]:
Creating template basic_package
Creating directory ./plone_basic
  Recursing into +package+
    Creating ./plone_basic/plone_basic/
    Copying __init__.py to ./plone_basic/plone_basic/__init__.py
  Copying setup.cfg to ./plone_basic/setup.cfg
  Copying setup.py_tmpl to ./plone_basic/setup.py
Running /home/Plone-4.3.3/Python-2.7/bin/python setup.py egg_info
Traceback (most recent call last):
  File "/home/Plone-4.3.3/zeocluster/bin/paster", line 259, in <module>
    sys.exit(paste.script.command.run())
  File "/home/Plone-4.3.3/buildout-cache/eggs/PasteScript-1.7.5-py2.7.egg/paste/script/command.py", line 104, in run
    invoke(command, command_name, options, args[1:])
  File "/home/Plone-4.3.3/buildout-cache/eggs/PasteScript-1.7.5-py2.7.egg/paste/script/command.py", line 143, in invoke
    exit_code = runner.run(args)
  File "/home/Plone-4.3.3/buildout-cache/eggs/PasteScript-1.7.5-py2.7.egg/paste/script/command.py", line 238, in run
    result = self.command()
  File "/home/Plone-4.3.3/buildout-cache/eggs/PasteScript-1.7.5-py2.7.egg/paste/script/create_distro.py", line 170, in command
    egg_info_dir = pluginlib.egg_info_dir(output_dir, dist_name)
  File "/home/Plone-4.3.3/buildout-cache/eggs/PasteScript-1.7.5-py2.7.egg/paste/script/pluginlib.py", line 135, in egg_info_dir
    % ', '.join(all))
IOError: No egg-info directory found (looked in ./plone_basic/./plone_basic.egg-info, ./plone_basic/setup.py/plone_basic.egg-info, ./plone_basic/plone_basic/plone_basic.egg-info, ./plone_basic/setup.cfg/plone_basic.egg-info)

Answer 1

workaround 1 :

The problem seems to be the missing setuptools . After installing setuptools, then paster (and all tools based on it) can run the generated setup.py. The following fixed the problem:

wget --no-check-certificate https://bootstrap.pypa.io/ez_setup.py -O - | sudo -u plone_buildout /usr/local/Plone-4.3.3/Python-2.7/bin/python

UnifiedInstaller-4.3.3 doesn't install setuptools. See this ticket .

As SteveM points out (see comments) this is not a recommended workaround.

(prefered) workaround 2 :

The generated data is there (despite the thrown error!) but setup.py will not run. Thus the Paste* directories will not be generated. Later when buildout runs it will generate/download the Paste* directories etc.

If you want setup.py to be run. You could patch PasteScript (at your own risk!).

As for PasteScript-1.7.5 go to line #587 of /path/to/Plone-4.3.3/buildout-cache/eggs/PasteScript-1.7.5-py2.7.egg/paste/script/command.py and get the current sys.path and pass it to subprocess.Popen() . This way the setup.py will run with the zopeskel or paste environment.

current_env = os.environ.copy()
current_env['PYTHONPATH'] = ':'.join(sys.path)
proc = subprocess.Popen([cmd] + list(args),
                        cwd=cwd,
                        stderr=stderr_pipe,
                        stdout=subprocess.PIPE,
                        env=current_env) # <- pass the env here

I'll try to figure out situations where this workaround could cause problems. I've posted an issue on PasteScript : https://bitbucket.org/ianb/pastescript/issue/16/pass-the-syspath-to-the-subprocess-in

Update : without generating/adding the Paste* dirs (either running buildout or by workaround as above) localcommands won't be available.