On Wed, 28 Oct 2009 12:26:19 +0900, David Cournapeau
> You can't ban setup.py: although ...
haha - of course.
ban setup.py as in ban alcohol or ban using a mobile phone when driving.
> With toydist, there would be a new build system not based on distutils,
> and which would indeed works like thi
Chris Withers wrote:
>
> From that I infer that most people use tools like buildout or pip to
> manage installation, even on Windows.
I am skeptical about this claim because up to recently, virtualenv did
not even work correctly for windows when you needed to build a C
extension (bug which has bee
David Lyon wrote:
> On Tue, 27 Oct 2009 16:52:36 +, Chris Withers
> wrote:
>
>> from distutils.core import setup,parse_static
>> setup(**parse_static('setup.cfg').to_dict())
>>
>> ...and of course, because setup.cfg is the default name, we just end up
>> with:
>>
>> from distutils.core imp
On Tue, 27 Oct 2009 16:52:36 +, Chris Withers
wrote:
> from distutils.core import setup,parse_static
> setup(**parse_static('setup.cfg').to_dict())
>
> ...and of course, because setup.cfg is the default name, we just end up
> with:
>
> from distutils.core import setup
> setup()
Nice..
But
On Tue, 27 Oct 2009 20:06:11 -0400, Glyph Lefkowitz
> If you're concerned about security and distutils, there is a _lot_ of
> work to do. There is no particular additional danger in executing
> a .exe rather than a setup.py.
Come to think of it.. you're totally right..
:-(
David
On Tue, 27 Oct 2009 18:51:07 -0500, Robert Kern
wrote:
> easy_install does not execute the executable. bdist_wininst installers
are
> zip
> files concatenated with an executable header. easy_install just unzips
the
> file
> as if it were a zipped egg and ignores the executable part.
Ok - well
On Oct 27, 2009, at 7:41 PM, David Lyon wrote:
I'm not sure about that Tarek..
An .exe installer as a perfect binary format for python packages?
Are you serious?
That is the biggest security threat I can think of, asking python
users to run unverified, unsigned, un-trusted executable files o
On 2009-10-27 18:41 PM, David Lyon wrote:
On Tue, 27 Oct 2009 20:51:10 +0100, Tarek Ziadé
wrote:
$ easy_install your_bdist_wininst_dist.exe
will install it and process the dependencies from the install_requires
option.
And pip should be compatible soon too. That makes this format a
perfect bi
On Tue, 27 Oct 2009 20:51:10 +0100, Tarek Ziadé
wrote:
> $ easy_install your_bdist_wininst_dist.exe
>
> will install it and process the dependencies from the install_requires
> option.
>
> And pip should be compatible soon too. That makes this format a
> perfect binary format for win32.
I'm no
On Tue, Oct 27, 2009 at 7:16 PM, Paul Moore wrote:
> Maybe someone has confused me. I understood that easy_install can
> consume bdist_wininst format .exe files just as easily as .egg format,
> and easy_install will do your dependency management for you.
That's exactly the case, you are not wrong
On Tue, Oct 27, 2009 at 12:26 PM, Chris Withers wrote:
> You're ignoring the fact that for the information in install_requires to
> even be parsed, you need to have setuptools present.
install_requires is processed at install time. At that time, clearly,
setuptools/distribute is present.
That's
2009/10/27 Chris Withers :
>>> My point is the bdist_win installers work fine for both your use case,
>>> Paul, and Chris' use case, so there's no real conflict.
>>
>> OK, and yet people still seem to argue for eggs rather than
>> bdist_wininst, and projects provide eggs rather than bdist_wininst.
Paul Moore wrote:
2009/10/20 Ian Bicking :
Well, I wanted to move it off python-dev, and I didn't really feel
like moving it onto distutils-sig because I felt the debate was not
particularly important to introduce the confusion of a half-started
thread.
Sorry, I hadn't realised it was on pytho
[adding in disutils-sig and leaving this message intact as that's where
it belongs]
Paul Moore wrote:
2009/10/20 Ian Bicking :
FWIW, I don't think there's a real conflict here. My understanding is
that wininst installers can be treated as installable packages that
don't *have* to go through t
Ronald Oussoren wrote:
Code should always specify their dependencies, not doing so will cause
you problems down the line...
Sure, and I do that for for any real code. But do you really expect that
users are careful to specify dependencies for each and every script they
write.
Yes, becau
David Lyon wrote:
ok. But nobody I know in software can stop new patches and versions
of software from being made. Versions advance.. For some it's even a
day job.
That's a poor argument for increasing the workload on all package
maintainers.
Backwards compatibility is the valid argument tha
David Lyon wrote:
but I want my proposed features implemented.. and code is the only
way to do it.
yes, but that code belongs in the standard library, not in each and
every single package distribution...
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
David Cournapeau wrote:
"""
from distutils.core import setup
from toydist import parse_static
info_dict = parse_static('toysetup.info').to_dict()
setup(**info_dict)
"""
Yep, this is the kind of thing I'm looking for.
Except if we're talking about the core, it would be:
from distutils.core imp
Tarek Ziadé wrote:
I thought the plan was to stick with major.minor and "==", "!=", "in" and
"not in" until PEP 386 was accepted, then switch over to having all versions
(including Python's) be some sort of Version object, at which point we can
have richer version comparisons, with all of the exi
Tarek Ziadé wrote:
On Tue, Oct 20, 2009 at 5:17 PM, Chris Withers wrote:
Tarek Ziadé wrote:
A quick scan of http://www.python.org/dev/peps/pep-0345/ shows no sign of
any of the contentious bits of PEP390. What am I missing?
That's the part I have not added yet. Markers are the "sys_platform =
Fred Drake wrote:
On Tue, Oct 27, 2009 at 11:35 AM, Chris Withers wrote:
I'm talking about *at all*.
If I don't include setuptools in install_requires, then I've no
business expecting it to be available at runtime.
You're ignoring the fact that for the information in install_requires to
e
On Tue, Oct 27, 2009 at 11:35 AM, Chris Withers wrote:
> I'm talking about *at all*.
If I don't include setuptools in install_requires, then I've no
business expecting it to be available at runtime. Since our current
approach in the Zope community is to use pkg_resources to support
namespace pac
Toshio Kuratomi wrote:
On Tue, Oct 20, 2009 at 02:48:58PM +0100, Chris Withers wrote:
Fred Drake wrote:
On Tue, Oct 20, 2009 at 9:39 AM, Chris Withers wrote:
As is specifying the setuptools distribution as a requirement when you're
already using it...
I don't use setuptools at runtime unless
On Tue, Oct 27, 2009 at 3:26 PM, sstein...@gmail.com
wrote:
>> That's done with the special "fixes #N" bit in the commit messages,
>> where N is the issue number. Bitbuckets links the tyicket with the
>> commits when its pushed there. So we could maybe add the link to the issue
>> in CHANGES ?
>
On Oct 27, 2009, at 10:21 AM, Tarek Ziadé wrote:
Maybe something like a TEST_README documenting the tests that prove
the that
the closed ticket's bugs have a test that proves that the former bad
behaviour was fixed.
Maybe a simpler way would be to use Bitbucket issue tracker features ?
Ar
On Tue, Oct 27, 2009 at 3:12 PM, sstein...@gmail.com
wrote:
>
> On Oct 27, 2009, at 4:53 AM, Tarek Ziadé wrote:
>
>> Hello
>>
>> We are going to release 0.6.7 this week. Among some new bugs fixes, we
>> want to provide a specific change that will
>> allow virtualenv to be released with an option t
On Oct 27, 2009, at 4:53 AM, Tarek Ziadé wrote:
Hello
We are going to release 0.6.7 this week. Among some new bugs fixes, we
want to provide a specific change that will
allow virtualenv to be released with an option to use Distribute
instead of Setuptools, like zc.buildout.
$ virtualenv --dis
Hello
We are going to release 0.6.7 this week. Among some new bugs fixes, we
want to provide a specific change that will
allow virtualenv to be released with an option to use Distribute
instead of Setuptools, like zc.buildout.
$ virtualenv --distribute ENV
If you want to see another bug fixed in
28 matches
Mail list logo
