classification
Title: Missing dependency in distutils build
Type: behavior Stage: patch review
Components: Distutils Versions: Python 3.4, Python 3.3, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: eric.araujo Nosy List: alexis, do3cc, eric.araujo, tarek
Priority: normal Keywords: patch

Created on 2009-02-13 09:57 by do3cc, last changed 2014-03-13 03:58 by eric.araujo.

Files
File name Uploaded Description Edit
dependency.patch do3cc, 2009-02-13 09:57 A Patch to fix the bug
test_install_lib.py do3cc, 2009-02-15 23:52 a rudimentary test case
test_install_lib.py do3cc, 2009-02-23 19:23
Messages (12)
msg81892 - (view) Author: Patrick Gerken (do3cc) Date: 2009-02-13 09:57
When running the command install_lib, the command build_clib is not run.
If a package contains clibs they can be dependencies for extension libs,
at least that is stated in the module docstring of build_clib.

In real life you can see it when trying to run the command install_lib
on the current reportlab2.3.

The patch provided needs do be applied in the distutils dir directly with

patch install_lib.py dependency.patch

As requested, I asked on the mailing list first, whether this really is
a bug. 
http://mail.python.org/pipermail/distutils-sig/2009-February/010974.html

I am half finished writing a test case, that I'll append to this ticket
later.
msg81894 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-02-13 10:02
be careful to write your test in distutils (setuptools is not part of
Python)
msg82187 - (view) Author: Patrick Gerken (do3cc) Date: 2009-02-15 23:52
The attached test works breaks without the patch and passes with the patch.

I am not sure whether the test itself is written following best practice.
I would be more than happy for a review, with hints what should be done
better.
msg82189 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-02-16 00:00
The patch looks good.

Minor tweaks :

- sys.path should be set to its initial state after the test
(setUp/tearDown might be helpfull here)

- ensure_finalized() should be called right before run() 
  so it acts like the real call
msg82637 - (view) Author: Patrick Gerken (do3cc) Date: 2009-02-23 19:23
Thank you, tarek

The sys.path should have been obvious.
msg94078 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-10-15 08:23
It looks like there's a missing part in the patch: get_outputs(), and
get_inputs() should also return files created in build()

Now something I don't understand is how reportlab distribution is doing
to copy the compiled extensions when "install" is called.

Could you point me please to the package so I can test that ?

Thanks !
msg94614 - (view) Author: Patrick Gerken (do3cc) Date: 2009-10-28 08:32
Hi Tarek,

I think clib stuff is installed in the right python directory and the 
ext install step then just finds them.

To reproduce the issue, run 
the "old" easy_install in a virtualenv.
easy_install ReportLab
It will then fail because of the missing library.

I can also show it during Plone Conference, just look for me in irc.

Thanks,

      Patrick
msg115784 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-09-07 15:55
Adding back distutils1. This is a bug, not a feature.
msg128497 - (view) Author: Alexis Metaireau (alexis) * Date: 2011-02-13 14:23
Has the patch been applied on distutils(1/2) ?
msg128510 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-02-13 15:41
If we haven’t closed it, it’s because it has not been.
msg138117 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-06-10 17:15
>> Now something I don't understand is how reportlab distribution is doing
>> to copy the compiled extensions when "install" is called.
> I think clib stuff is installed in the right python directory and the
> ext install step then just finds them.
Yep, the install* commands just copy all files from the build dir to the install dir.

The patch is straightforward and the test looks good.  However, I worry about backward compatibility.  For projects without C libs, this won’t change anything; for projects already having a workaround, what will happen?  While this is clearly a bug, I’m not sure fixing the existing behavior is okay in distutils.

For packaging (distutils2), I will commit this shortly.
msg138205 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-06-12 11:06
> for projects already having a workaround, what will happen?
I think I have the answer to my question: if build_clib is called twice, the registry in Distribution will know that it has run and won’t run it again.  I’ll test manually and if I confirm, I will commit this change.
History
Date User Action Args
2014-03-13 03:58:32eric.araujosetcomponents: - Distutils2
versions: + Python 3.4, - 3rd party, Python 3.2
2011-06-12 11:06:27eric.araujosetassignee: tarek -> eric.araujo
messages: + msg138205
2011-06-10 17:15:36eric.araujosetresolution: accepted ->
stage: patch review
messages: + msg138117
versions: + Python 3.3, - Python 3.1
2011-02-13 15:41:48eric.araujosetnosy: tarek, eric.araujo, do3cc, alexis
messages: + msg128510
2011-02-13 14:23:15alexissetnosy: + alexis
messages: + msg128497
2010-09-29 23:43:03eric.araujosetversions: + 3rd party
2010-09-07 15:55:53eric.araujosetmessages: + msg115784
2010-09-07 15:54:49eric.araujosetnosy: + eric.araujo

components: + Distutils
versions: - Python 2.6, Python 2.5, Python 3.0, Python 3.3
2010-04-20 15:44:24eric.araujosetcomponents: + Distutils2, - Distutils
versions: + Python 2.5, Python 3.1, Python 3.3
2009-10-28 08:32:59do3ccsetmessages: + msg94614
2009-10-15 08:23:20tareksetpriority: normal
resolution: accepted
messages: + msg94078

versions: + Python 3.0, Python 3.2, - Python 2.5, Python 2.4
2009-02-23 19:23:04do3ccsetfiles: + test_install_lib.py
messages: + msg82637
2009-02-16 00:00:26tareksetmessages: + msg82189
2009-02-15 23:52:16do3ccsetfiles: + test_install_lib.py
messages: + msg82187
2009-02-13 10:02:23tareksetmessages: + msg81894
2009-02-13 09:57:07do3cccreate