Re: Proposal: No more standard library additions

Martin v. Löwis wrote:

> If that is so, just ignore the warnings.

Not acceptable, because it means I have to examine
all the warnings every time I compile to check that
another one hasn't appeared that represents a real
problem.

> one way to solve the problem is to make the warnings
> go away.

The most straightforward way to solve the problem
is not to ask for these warnings in the first place.
Or at least it would be if I had a decent amount of
control over what warnings get asked for.

> I'm wondering what a make-like system would look
> in this case. Would I write
> 
> $(TARGETDIR)/foo/bar.py: foo/bar.py
>     cp foo/bar.py $(TARGETDIR)/foo/bar.py

Don't take "make-like" too literally. All I mean
is something organised around a dependency graph
rather than a list of things to do one after the
other.

The nodes in the graph needn't be individual files.
The whole package-to-be-build would be a node,
which would depend on the nodes representing the
.py files.

The specification would probably look fairly
similar in some ways to what you currently pass
to the setup function, i.e. a list of .py files that
go into the package. But the internal structure
would be built out of dependency graph nodes
rather than commands and sub-commands.

> If you look at Python's "make install" rule, you
> might agree that "install" is not something that
> plain old make is very good at.

I agree that Make itself doesn't handle install-type
operations very well. I think that's partly because
it's too rigidly fixated on a target being a single
file.

--
Greg