Edgewall Software
Modify

Ticket #313 (closed defect: wontfix)

Opened 23 months ago

Last modified 23 months ago

setup.py allows fallback to setup from distutils.core instead of setuptools but then fails on install phase

Reported by: bkohler@… Owned by: fschwarz
Priority: major Milestone: 1.0
Component: General Version: 0.9.6
Keywords: Cc:

Description

The setup.py script first calls "from setuptools import setup" but allows fallback to "from distutils.core import setup". When setuptools is missing/broken and it falls back to distutils setup, the install phase seems to fail silently, or at least produce an incomplete result.

I am trying this on Gentoo Linux so my build log is clearly using portage, but I believe this issue affects everyone. During the build phase with distutils setup, some warnings are thrown, then some more warnings during install, and the resulting install dir is very incomplete. There is no /usr/bin/pybabel, for example.

Attached is a diff between the "broken" setup's build/install output, and the "working" setup's build/install output.

Attachments

diff.log (2.7 KB) - added by bkohler@… 23 months ago.
diff of broken versus working build logs

Change History

Changed 23 months ago by bkohler@…

diff of broken versus working build logs

comment:1 Changed 23 months ago by fschwarz

  • Owner changed from cmlenz to fschwarz
  • Status changed from new to assigned
  • Milestone changed from unscheduled to 1.0

comment:2 Changed 23 months ago by fschwarz

  • Status changed from assigned to closed
  • Resolution set to wontfix

Unfortunately there is nothing we can do about that as far as I know.

One minor issue are the warnings about "unknown distribution option"s. I fixed that in trunk (#262).

egg_info is a feature of setuptools, so that's obviously not being generated with distutils.

Probably the biggest issue to you is the missing pybabel script. AFAIK there is no good way to install an application in the bin directory using distutils like we can do that with setuptools. So no pybabel with distutils.

A missing pybabel is not a blocker for Babel as Babel can be used purely as an API (format_date, format_currency, ...) so it's useful without pybabel. Personally I'd just require setuptools (as I find it a bit silly not to have setuptools) but there are other developers who like distutils-only.

comment:3 Changed 23 months ago by bkohler@…

We do require setuptools for Babel, but the difficulty comes when a user has a previously-built setuptools that only has support for python3, and hasn't YET been built for python2. But it still satisfies Babel's dep, and Babel does not report any failure. Then pybabel is missing but Babel is "successfully installed" already, very confusing.

I suppose this is a limitation of portage's deps & python functionality right now. Is there any way to tell the Babel build system "We *require* pybabel, fail/abort if you cannot build it"?

At this point I'm 95% sure we will need to fix this downstream, I just want to do my homework so they don't send me to you guys again.

Thanks!

comment:4 follow-up: ↓ 5 Changed 23 months ago by fschwarz

Just so I understand the problem correctly: portage does not have any clue if setuptools was installed for Python 2 vs. Python 3? If I remember correctly, portage does not track Python versions at all, right? rpm/Fedora/EPEL handles that by prefixing the package name with Python's version number, e.g. 'python26-', 'python3-', ...).

Currently Babel just uses a silent fallback without any option to override. The simplest option I see here is to patch Gentoo's Babel package (just remove the fallback in setup.py).

Another viable approach could be that Babel exits with an error if setuptools is not installed and enable the user to override that using '--without-setuptools'. However that option should be discussed on Babel's mailing list first. Given that pybabel is arguably a major part of Babel's functionality I'd be in favor of such a patch.

comment:5 in reply to: ↑ 4 Changed 23 months ago by bkohler@…

Replying to fschwarz:

Just so I understand the problem correctly: portage does not have any clue if setuptools was installed for Python 2 vs. Python 3?

This is *currently* the case, yes. Our "python-updater" tool can detect this setuptools breakage, but that's not checked @ Babel build time. Some new python handling stuff seems to be in the works, though.

Currently Babel just uses a silent fallback without any option to override. The simplest option I see here is to patch Gentoo's Babel package (just remove the fallback in setup.py).

I've proposed that in the gentoo bug report here, for a temporary workaround: https://bugs.gentoo.org/show_bug.cgi?id=431278#c1 , but I'm sure our maintainers would much prefer an upstream fix for a long term resolution. I will look into proposing the "--without-setuptools" idea, but that proposal may need to come from someone with more python knowledge than myself.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.