"Fredrik Lundh" <fredrik@pythonware.com> writes:
> alex wrote:
>
> > The "problem" (:-) is that it's great at just building extensions, =
> too.
> >=20
> > python2.1 setup.py install, python2.2 setup.py install, python2.3 =
> setup.py=20
> > install, and hey pronto, I have my extension built and installed on =
> all=20
> > Python versions I want to support, ready for testing. Hard to beat!-)
>
> does your code always work right away?
>
> I tend to use an incremental approach, with lots of edit-compile-run
> cycles. I still haven't found a way to get the damn thing to just build
> my extension and copy it to the current directory, so I can run the
> test scripts.
>
> does anyone here know how to do that, without having to resort to
> ugly wrapper batch files/shell scripts?
Nope. I guess
class install_local(distutils.command.install.install):
...
would be one way. Perhaps it should be built in.
> (distutils is also a pain to use with a version management system
> that marks files in the repository as read-only; distutils copy function
> happily copies all the status bits. but the remove function refuses to
> remove files that are read-only, even if the files have been created
> by distutils itself...)
Yeah, this area sucks. It interacts v. badly with umask, too. Maybe
I'll work on this bug instead on my next train journey... installing
shared libraries with something like copy_tree is gross.
Cheers,
M.
--
Counting lines is probably a good idea if you want to print it out
and are short on paper, but I fail to see the purpose otherwise.
-- Erik Naggum, comp.lang.lisp
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4