[Pythonmac-SIG] Exclude certain files from py2app built apps

[Olivier Cornu]

On Mon, May 13, 2013 at 7:15 PM, Ronald Oussoren <ronaldoussoren at mac.com>wrote:

>
> On 13 May, 2013, at 18:55, Olivier Cornu <o.cornu at gmail.com> wrote:
>
> > Well, on my machine (Linux/Python-2.7), it seems bdist, bdist_rpm and
> bdist_egg (among others) do generate an egg-info directory following
> MANIFEST.in directives, just like sdist. Which appears to contradict your
> point; Or did i miss something?
>
> But does bdist_egg actually include those files (I'm too lazy to check
> this right now)?
>

It does include the egg-info directory (renamed in capitals EGG-INFO). It
doesn't include MANIFEST(.in).


> The goals of the various command's are different.  In particular, your
> MANIFEST.in will normally include files that aren't needed at runtime, such
> as the ReadMe file, other documentation and examples. Those should be
> included in the sdist, and possibly be installed, but aren't needed in an
> application bundle (or a windows executable created with py2app).
>

> Distutils, and by extension setuptools, does not really have a formal
> description of its behavior the behavior is more or less an accumulation of
> years of development by different people that do not necessarily have deep
> knowlegde of distutils.  And that's just the core project, external tools
> like py2app are a whole different story (and I write that as the py2app
> maintainer).
>

I appreciate that. A rather common situation in the open-source world i
believe: the project i'm working on, although smaller and less central to
the community, fits the descriptions just as well…
Yet regarding data_files, if i understand correctly there are two, perhaps
three interpretations of what it means (where to install data files? Which
data file gets included? Both?). We're talking about the same argument of
the same function of the same module, here.
I mean, i understand different heuristics are chosen by different people in
different situations. I understand misunderstanding or going around frozen
interfaces to get to one's ends. Yet i don't think i'm putting the API
convergence bar very high either by expecting one function argument to mean
just one thing. If it has to mean something else, why not just call it
differently? As it is, with no documentation whatsoever, it is as effective
a trap as one could willingly design… ;)


> In the long run distutils will likely be replaced by better tools, the
> folks over on the distutils-sig are working on that. The first steps, that
> are making good progres, and to create a binary distribution format
> ("wheels") as the interface between a build-tool (like distutils) and an
> installation tool (like easy_install or pip), and a well defined
> installation format.  Followup steps will define other interfaces (such as
> a way the installer can detect which build tool it should use to convert an
> sdist into a binary distribution for installation).  With some luck Python
> 3.4 will include at least support for the wheel format and a basic
> installer.
>

Well, thanks for the update: that looks exciting! Where can i learn more
about it?
___
ɹǝıʌıןo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20130513/813d98d8/attachment-0001.html>