Priority: 4
Keywords: patch, distutils, pyc
Comment:
I posted this on the distutils mailing list, and they said I should post
it here instead.

---
Hi,
I'm certaintly new to distutils and setuptools, however I figured I'd
send in this patch, and either it will get merged because it's a great
idea or someone will perhaps tell me why this doesn't exist already.
(or maybe it does and i can't find it)
In any case, it adds the pyc option to the clean command so that the
.pyc can be removed on request. Personally i'll have a [clean] pyc=1
option in my setup.cfg, but that's for my convenience.
cheers,

_J


---

ps: i wasn't able to pick a priority or keywords, there isn't a box to
type those in, however the titles are there. so either i don't have
permissions or there's a bug ?

The clean command cleans up temporary files from 'build' command.

Your patch removes files that are not generated by the build command only
but by a normal usage of Python modules.

Why do you need to remove them precisely ?

Hi, the patch only removes them if one adds the --pyc option.
I think it is a good idea to have some option or target somewhere to
remove the types of files that can be regenerated because often
developers want to "get them out of the way". Example: I'll be working
on a project in my code directory, and it's nice to be able to do an "$
ls" without seeing extra files lying that clutter up the view. Perhaps
different people want to remove them for different reasons. I remember
searching for "remove .pyc" or something like it and it returned some
hits from other people wanting similar functionality. Thanks for your
time, I hope you include something like this patch in upstream.

_J

It seems to me that this functionality is similar to what a 'distclean'
target would do in a typical makefile.  Don't know if that perspective
helps any :)

I don't think distutils should host whetever functionality useful to
developers. Distutils is for packaging and distributing Python software.

I could agree with R. David Murray, and I think that it's fine that this
be included under a dist clean command.
Ultimately I'm writing an application and I'm trying to use distutils
with it. I'll potentially run a: "$ setup.py build_ext -i" or whatever
it may be, and then I'll want to get rid of all the mess. So I'll want
to run a clean. If that clean won't get rid of .pyc for me in one
command, then i have to run a second shell script to clean my dir,
instead of sticking the two together. Which is why i think a clean --pyc
option is useful (off by default) and which I can easily enable in
setup.cfg with [clean] pyc=1
I think this is harmless. Anyone agree?

thanks!
_J

I'm not sure why you call it a "mess". Generating a pyc file is the
normal way of operating when importing a Python module from source. It's
not just distutils.

And the fact that it's "harmless" does not justify adding a distutils
option for something which doesn't seem to have anything to do with
distutils...

ps: included is a platform independent version of the code, so that it
doesn't depend on os.system() specific commands.

HTH,
_J

Antoine: Okay sorry not a mess then.
I just figure that if i'm using the distutils tool for doing all the fun
things to my local source directory that I potentially used to do with
say a makefile, then would it not be beneficial to have a useful
-option- (as included in the patch). It won't affect any previous
distutils setups, and can only benefit future users. Why not?

_J

The only reason I would see to clean .pyc file in distutils clean
command is if the build command (or any other command) would generate
them in the source tree, which is not the case.

That said, build_ext -i *does* create .so files in the source tree, so
we should provide a way to remove them I think.

Currently, I have (had) a make file with a clean target that would
remove these files. Would you recommend keeping this file and it's
associated functionality, or is the idea to be able to integrate this
into distutils and be able to do away with makefiles for python projects?

I'm aware that I can subclass Command and make my own "target"... I've
done this, but it seems to me it's better suited upstream.

Hello

So, is this bug “add a distclean command” now?

Regards

i'm fine with that and willing to contribute patches, however i would feel better if whoever upstream was, was more supportive of the idea.
someone let me know.

a thought:
- it's true (as mentioned) that distclean isn't necessarily directly related to distributing python scripts, however (in my mind anyways) i see distutils as a replacement for common things we do in makefiles. so as a result if we did this we could get rid of makefiles and provide useful "action" targets such as distclean, test, etc... 100% pure python if needed...

Discussion summary:
- clean is supposed to remove the products of build
- build_ext is a subcommand of build
- build_ext with the inplace option writes files that are not removed by clean
- removing .pyc files is out of scope (they’re products of normal Python behavior, not related to distutils)
→ I’m reclassifying this as a distutils2 feature request concerning the products of build_ext --inplace.

I’m not sure whether we should remove those products when the --all option is given to clean, or add a new option that we could enable by default.

New changeset 67ada6ab7fe2 by Éric Araujo in branch '2.7':
Clarify distutils’ clean command (ref #6142)
http://hg.python.org/cpython/rev/67ada6ab7fe2

New changeset 066b896b6132 by Éric Araujo in branch '3.3':
Clarify distutils’ clean command (ref #6142)
http://hg.python.org/cpython/rev/066b896b6132

New changeset 50ee8fe8e841 by Éric Araujo in branch 'default':
Clarify distutils’ clean command (ref #6142)
http://hg.python.org/cpython/rev/50ee8fe8e841

distutils doc now warns about clean not removing extensions built in place.  distutils2 is no more.  Closing.