Hi !

when specifying additional files to be distributed by distutils.core.setup, documentation says that:

"Each file name in files is interpreted relative to the setup.py script at the top of the package source distribution. No directory information from files is used to determine the final location of the installed file; only the name of the file is used"

(http://docs.python.org/py3k/distutils/setupscript.html#distutils-additional-files)

Well, this seems to be incorrect - I tried to specify a file from a higher level directory, which get's copies to a target based on the whole path I specified, not just the name...

Pls. see attached file for details

Thanks for the report.

“No directory information from files is used to determine the final location of the installed file; only the name of the file is used”

I understand this line to mean that only the basename of the file will be used in the target directory, IOW that ('config', ['cfg/data.cfg']) will create a file in config/data.cfg, not config/cfg/data.cfg.  I’m not 100% sure about my reading though, this line is confusing.

Paths starting with '..' are relative, even if they’re not under the top-level directory of the project (do the docs say they should be?), so the ability to give '../../spam/whatever' as data file looks okay.  However, it should not be installed to target_dir/../../spam, that’s definitely a bug (coming from os.path.join in cmd.Command.copy_file, I think).

If you want to write a test and fix, there are some guidelines at http://wiki.python.org/moin/Distutils/FixingBugs

On Wed, Jan 19, 2011 at 12:42 PM, Éric Araujo <report@bugs.python.org> wrote:
> I understand this line to mean that only the basename of the file will be used
> in the target directory, IOW that ('config', ['cfg/data.cfg']) will create a
> file in config/data.cfg, not config/cfg/data.cfg.
>  I’m not 100% sure about my reading though, this line is confusing.

This is my reading as well.

See also #9261.

Hi Éric, All,

thank you for the directions you gave me!
It's all about a call of os.path.basename() missing in sdist.py. Pls. see attached diff.

Regards,
Thorsten

Thanks for the patch.  Would you like to complete it?  It lacks tests, and I think the fix may be in the wrong place: You fixed sdist but not bdists.  I think the root of the problem is in the manifest (distutils2) / filelist (distutils1) module.

(We want to fix bugs in distutils2 first and then backport them to d1, as explained in the short guidelines I linked to in msg126545, which I advise you to read.)

I have added a test for the modification in msg127191. Though, inside zip-file we get files without its parent dir, nothing changes in manifest file(should it change?). Please have a look at the changeset https://bitbucket.org/pkumar/distutils2_bugs/changeset/7473385c23f2.

Looks great, thanks.  You haven’t addressed this part of my previous message: “I think the fix may be in the wrong place: You fixed sdist but not bdists.  I think the root of the problem is in the manifest (distutils2) / filelist (distutils1) module.”

I don’t understand this comment: “Though, inside zip-file we get files without its parent dir, nothing changes in manifest file(should it change?).”

This bug should be fixed in packaging and distutils2, but I’m not sure about distutils: it’s an important change in behavior.  Tarek, Fred, what do you think?

I made changes in manifest.py which can be viewed here: https://bitbucket.org/pkumar/distutils2_bugs/changeset/111c1253ea7a

I'm not sure if I should modify test_command_sdist.py for the failing tests of manifest contents(since it is mentioned not to edit). 

msg133834:
>> I don’t understand this comment: “Though, inside zip-file we get files without its parent dir, nothing changes in manifest file(should it change?)

code from test_command_sdist.py:

        zip_file = zipfile.ZipFile(join(dist_folder, 'fake-1.0.zip'))
        try:
            content = zip_file.namelist()
        finally:
            zip_file.close()
after the change as mentioned in msg127191, the value of content changed, i.e. 'fake-1.0/some/other_file.txt' was changed to 'fake-1.0/other_file.txt'.But modifications were still required for the manifest. Above change should serve the purpose, I guess.

The “remote hg repo” is supposed to be the URI of a clone (not of a changeset) of cpython (not distutils2), so the repos you added don’t work.  Can you remove them and add a patch file instead?  Thanks.

The first changeset looks good; I don’t understand the second one.

> I'm not sure if I should modify test_command_sdist.py for the failing
> tests of manifest contents
Hm.  It looks like the tests were in contradiction with the docs.  The safest way here is to fix the behavior in packaging/d2 and mention the bug in the distutils docs.

> (since it is mentioned not to edit).
It’s a comment aimed at software developers reading the generated MANIFEST file, not at distutils2 hackers working on the tests :)  See #8688.

If I'm not wrong, the contents in the manifest file should be:
 'data.cfg' (not cfg/data.cgg)
 I've added a patch which fixes the above issue.

Can you remove all obsolete repositories and patches from this report and upload one complete patch?

Sure, patch.diff is a complete one.

Patch looks good.  Detail: I’d find a call to basename more readable than i.split('/')[-1:][0].

Does this need a test in test_manifest too?  A doc update?

Certainly, a test is needed to check that ('config', ['cfg/data.cfg']) would create a file in config/data.cfg and not config/cfg/data.cfg.

Though, I've added a patch 'test_command_sdist.diff' for the changes made in 'patch.diff'.

This issue is 8 years old has 4 patches: it's far from being "newcomer friendly", I remove the "Easy" label.

Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.

If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools