I am having troubles working with setuptools on Solaris. The Solaris
operating system normally installs modules as packages which contain
binaries. This is unlike other Linux operating systems where, for
exmaple, an RPM would download the source and build it on the user's
machine when they in
Ian Bicking wrote:
> Rick Warner wrote:
>>> Actually, PyPI is replicated. See, for example,
>>> http://download.zope.org/simple/.
>>>
>>> It may be that some of the mirrors should be better advertised.
>>
>> A half-hearted effort. at best, after the problems last year. When I
>> configure a CPAN
Ian Bicking wrote:
FWIW, pyinstall can collect all the packages before installing any of
them. You do have to download all packages, though, as that's the only
way to get the metadata.
This may be something to make sure is on the requirements
list for a metatdata standard: Make sure there is
Josselin Mouette wrote:
if you try to
build a package of baz, there is no way to express correctly that you
depend on python-bar (>= 1.3) or python-foo (>= 1.2).
Seems to me that baz shouldn't have to say that -- all it
should have to say is that it requires bar version 1.3.
It's up to the pack
This is as-documented. Per the docs:
"""If a package is built from a source distribution or checkout, it
will be extracted to a subdirectory of the specified directory."""
That is, --build-dir applies only to SVN checkouts (done by
easy_install itself) and source distributions (i.e. sdist zi
Pascoe, S (Stephen) wrote:
I often just want to do with easy_install is download an egg from pypi without installing
it. I've studied the easy_install documentation and never found a way to do it. Even
giving it the "-d" option results in easy-install.pth being created and other
unwanted stu
Josselin Mouette wrote:
Le mardi 30 septembre 2008 à 15:46 -0500, Dave Peterson a écrit :
Josselin Mouette wrote:
No, please stop here. That’s not OK. If a new version of HardJSON breaks
your application, it is friggin’ broken. If that new version is not
compatible, it should be called
On Tue, 30 Sep 2008 23:32:14 +0200, Josselin Mouette <[EMAIL PROTECTED]> wrote:
[snip]
The marketing name does not have to be the same of the name of the
module you import. The situation where they differ is even quite common.
You can also argue for separating the name from the API version, lik
I often just want to do with easy_install is download an egg from pypi without
installing it. I've studied the easy_install documentation and never found a
way to do it. Even giving it the "-d" option results in easy-install.pth being
created and other unwanted stuff.
Looking at the setuptoo
Le mardi 30 septembre 2008 à 15:46 -0500, Dave Peterson a écrit :
> Josselin Mouette wrote:
> > No, please stop here. That’s not OK. If a new version of HardJSON breaks
> > your application, it is friggin’ broken. If that new version is not
> > compatible, it should be called HardJSON2, and nothin
New submission from Zooko O'Whielacronx <[EMAIL PROTECTED]>:
It seems like if the argument to easy_install is a local file instead of a
distribution name, then it ignores the --build-directory option:
easy_install -v -v -v --prefix=./instdir --build-directory=./builddir
./pyutil-1.3.21.tar.gz |
Chris Withers wrote:
>> Contributions are welcome. The source code of PyPI is available
>> publically,
>
> Where?
https://svn.python.org/packages/trunk/
>> and I'm willing to accept patches. I won't have time
>> to work on this in the next 12 months myself.
>
> These two don't seem to go hand
Josselin Mouette wrote:
Le mardi 30 septembre 2008 à 11:37 -0500, Ian Bicking a écrit :
Say I have a package that represents an application.
[snip]
Then HardJSON 2.0 is released, and Turplango only required
HardJSON>=1.2, so new installations start installing HardJSON 2.0. But
my
On Tue, Sep 30, 2008 at 8:21 PM, Rob Cakebread <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 30, 2008 at 10:51 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> At 12:25 PM 9/30/2008 -0400, A.M. Kuchling wrote:
>>>
>>> On Tue, Sep 30, 2008 at 10:41:11AM -0500, Ian Bicking wrote:
>>> > FWIW, pyinstall can
Martin v. Löwis wrote:
That said, I didn't see any indication of what I consider to be a
critical failure in PyPI: No dependency metadata prior to downloading
the package.
Contributions are welcome. The source code of PyPI is available
publically,
Where?
and I'm willing to accept patches.
Chris Withers a écrit :
> > Hi All,
> >
> > I've been trying to catch up on all the packaging discussions but
> > couldn't find the right place to reply so thought I'd just do so
> > seperately...
Maybe, we have all our own definition ...
> >
> > Probably the biggest thing that strikes me now is th
> That said, I didn't see any indication of what I consider to be a
> critical failure in PyPI: No dependency metadata prior to downloading
> the package.
Contributions are welcome. The source code of PyPI is available
publically, and I'm willing to accept patches. I won't have time
to work on thi
Le mardi 30 septembre 2008 à 11:37 -0500, Ian Bicking a écrit :
> Say I have a package that represents an application.
[snip]
> Then HardJSON 2.0 is released, and Turplango only required
> HardJSON>=1.2, so new installations start installing HardJSON 2.0. But
> my app happens not to be compatib
> What do other people feel?
Open Standards. Standardizing data format rather than tools. Well
defined public PyPI API... of course I agree with you!
--
Nicolas Chauvat
logilab.fr - services en informatique scientifique et gestion de connaissances
_
On Tue, Sep 30, 2008 at 10:51 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:25 PM 9/30/2008 -0400, A.M. Kuchling wrote:
>>
>> On Tue, Sep 30, 2008 at 10:41:11AM -0500, Ian Bicking wrote:
>> > FWIW, pyinstall can collect all the packages before installing any of
>> > them. You do have to do
At 12:25 PM 9/30/2008 -0400, A.M. Kuchling wrote:
On Tue, Sep 30, 2008 at 10:41:11AM -0500, Ian Bicking wrote:
> FWIW, pyinstall can collect all the packages before installing any of
> them. You do have to download all packages, though, as that's the only
> way to get the metadata.
Does the DOA
On Tue, Sep 30, 2008 at 10:41:11AM -0500, Ian Bicking wrote:
>> There is nothing that I hate more than easy_install failing after having
>> half-installed a package because of a missing dependency. This is one of
>> the reasons I am never too happy when I have to run easy_install.
>
> FWIW, pyinsta
Tarek Ziadé wrote:
So... that's the kind of thing I encountered with just a couple
dependencies, but in practice it was much worse because there were a lot
more than 3 libraries involved. I now think it is best to only use version
requirements to express known conflicts. For future versions of
On Tue, Sep 30, 2008 at 6:37 PM, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Chris Withers wrote:
>>
>> Tarek Ziadé wrote:
Tarek Ziade wrote:
>
> For KGS I agree that this is a big work, but there's the need to work
> at a
> higher level that in your package
Why? Yo
Chris Withers wrote:
Tarek Ziadé wrote:
Tarek Ziade wrote:
For KGS I agree that this is a big work, but there's the need to
work at a
higher level that in your package
Why? You really need to explain to me why the dependency information
in each
of the packages isn't enough?
Because you can
A.M. Kuchling wrote:
On Tue, Sep 30, 2008 at 10:41:11AM -0500, Ian Bicking wrote:
FWIW, pyinstall can collect all the packages before installing any of
them. You do have to download all packages, though, as that's the only
way to get the metadata.
Does the DOAP output for a package not con
On Tue, Sep 30, 2008 at 10:41:11AM -0500, Ian Bicking wrote:
> FWIW, pyinstall can collect all the packages before installing any of
> them. You do have to download all packages, though, as that's the only
> way to get the metadata.
Does the DOAP output for a package not contain enough metada
Le mardi 30 septembre 2008 à 17:08 +0100, Chris Withers a écrit :
> Josselin Mouette wrote:
> > It doesn’t have to go away per se, but we need proper ways to deal with
> > incompatible changes in the interfaces.
>
> Well, the generally accepted way seems to be to increase the major
> version numb
Ian Bicking wrote:
FWIW, pyinstall can collect all the packages before installing any of
them. You do have to download all packages, though, as that's the only
way to get the metadata.
...yes, and this is why PyPI should change!
Chris
--
Simplistix - Content Management, Zope & Python Consul
Tarek Ziadé wrote:
Tarek Ziade wrote:
For KGS I agree that this is a big work, but there's the need to work at a
higher level that in your package
Why? You really need to explain to me why the dependency information in each
of the packages isn't enough?
Because you can keep up with the depend
Josselin Mouette wrote:
Le mardi 30 septembre 2008 à 16:36 +0100, Chris Withers a écrit :
No, the problem we have today is that some developers are providing
modules without API stability, which means you cannot simply depend on a
module, you need a specific version.
This problem is never going
Hi All,
I've been trying to catch up on all the packaging discussions but
couldn't find the right place to reply so thought I'd just do so
seperately...
Probably the biggest thing that strikes me now is that
distutils/setuptools/distribute/pacman/whatever should aim to do much
less...
In
Le mardi 30 septembre 2008 à 16:36 +0100, Chris Withers a écrit :
> >> No, the problem we have today is that some developers are providing
> >> modules without API stability, which means you cannot simply depend on a
> >> module, you need a specific version.
>
> This problem is never going away, i
On Tue, Sep 30, 2008 at 5:55 PM, Chris Withers <[EMAIL PROTECTED]> wrote:
> Tarek Ziade wrote:
>>
>> For KGS I agree that this is a big work, but there's the need to work at a
>> higher level that in your package
>
> Why? You really need to explain to me why the dependency information in each
> of
Matthias Klose wrote:
Install debian and get back to productive tasks.
This is an almost troll-like answer.
See page 35 of the presentation.
I disagree. You could think of "Packages are Pythons Plugins" (taken
from page 35) as a troll-like statement as well.
You're welcome to your (incorrect
Tarek Ziade wrote:
For KGS I agree that this is a big work, but there's the need to work at
a higher level that in your package
Why? You really need to explain to me why the dependency information in
each of the packages isn't enough?
Python frameworks are exploding in a myriad of packags :
On Tue, Sep 30, 2008 at 5:41 PM, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Gael Varoquaux wrote:
>
>> On Tue, Sep 30, 2008 at 04:01:01PM +0100, Chris Withers wrote:
>>
>>> That said, I didn't see any indication of what I consider to be a
>>> critical failure in PyPI: No dependency metadata prior to
2008/9/30 Chris Withers <[EMAIL PROTECTED]>
> Tarek Ziadé wrote:
>
>> In other words the problem we have today with an OS-based installation is
that
you cannot really have two versions of the same package installed,
that would make happy
two Python applications.
>>>
> Righ
Le mardi 30 septembre 2008 à 17:20 +0200, Tarek Ziadé a écrit :
> > Again, when a C library changes its ABI, we do not allow it to keep the
> > same name. It's as simple as that.
>
> I see, so there's no deprecation processes for a package ?
Not per se. It is the job of the package manager to pr
On Tue, Sep 30, 2008 at 5:41 PM, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Gael Varoquaux wrote:
>>
>> On Tue, Sep 30, 2008 at 04:01:01PM +0100, Chris Withers wrote:
>>>
>>> That said, I didn't see any indication of what I consider to be a
>>> critical failure in PyPI: No dependency metadata prior t
Gael Varoquaux wrote:
On Tue, Sep 30, 2008 at 04:01:01PM +0100, Chris Withers wrote:
That said, I didn't see any indication of what I consider to be a critical
failure in PyPI: No dependency metadata prior to downloading the package.
+1. I want to be able do list all the packages an easy_insta
On Tue, Sep 30, 2008 at 04:01:01PM +0100, Chris Withers wrote:
> That said, I didn't see any indication of what I consider to be a critical
> failure in PyPI: No dependency metadata prior to downloading the package.
+1. I want to be able do list all the packages an easy_install run will
download
Tarek Ziadé wrote:
In other words the problem we have today with an OS-based installation is that
you cannot really have two versions of the same package installed,
that would make happy
two Python applications.
Right, which is why dependencies can often be best matched by a
project-based tool
Tarek Ziadé wrote:
I started to write a new PEP (well a wiki page in fact...) that
describes a new package called "pypi" that would be dedicated to package
registering and uploading mechanisms.
It would also provide enhancements like a proper password hash, or
deepers metadata controls
http:/
Tarek Ziadé wrote:
http://wiki.python.org/moin/DistributeSprint_#1
The dates on this make no sense...
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Distutils-SIG maillist -
On Tue, Sep 30, 2008 at 5:02 PM, Chris Withers <[EMAIL PROTECTED]> wrote:
> Tarek Ziadé wrote:
>>
>> http://wiki.python.org/moin/DistributeSprint_#1
>
> The dates on this make no sense...
I fixed the typo thanks. Please propose some other dates then over
there, if you wish
Keep in mind that peopl
Michael wrote:
Now, with python there's the general ethos:
There should be one-- and preferably only one --obvious way to do it.
And with perl there's the general ethos:
There's more than one way to do it
Anyone who's written extensive amounts of code in both languages will know
that the
On Tue, Sep 30, 2008 at 4:27 PM, Josselin Mouette <[EMAIL PROTECTED]> wrote:
>> In other words the problem we have today with an OS-based installation is
>> that
>> you cannot really have two versions of the same package installed,
>> that would make happy
>> two Python applications.
>
> And this
Nicolas Chauvat wrote:
Baseline is "no problem with providing egg-info metadata, but pretty
please Python developers, do not code *for* distutils/setuptools/etc.
Just find a way to provide useful dependency/meta information then let
your users choose how they install your code on *their* system".
Marius Gedminas wrote:
On Tue, Sep 23, 2008 at 09:24:00PM -0700, Kevin Teague wrote:
Or they can just use debian! Any debian developers out there up for
the task of packaging up the 1500+ odd packages released from the Zope
community?
The SchoolTool guys made a tool and built .debs for all
Le mardi 30 septembre 2008 à 15:49 +0200, Tarek Ziadé a écrit :
> The "Obsoletes" info could be used maybe. But the main problem I can
> see is that
> in any case several versions of the same module can be needed to build
> one application.
This is indeed a problem, and when it happens, it needs
Le mardi 30 septembre 2008 à 14:05 +0200, Tarek Ziadé a écrit :
> On Tue, Sep 30, 2008 at 10:42 AM, Nicolas Chauvat
> <[EMAIL PROTECTED]> wrote:
> > For example, if you require a minimal version of 1.4, you can
> > translate this to a package version of 1.4; it is a bit hackish but
> > will work if
On Tue, Sep 30, 2008 at 3:17 PM, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> Le mardi 30 septembre 2008 à 14:05 +0200, Tarek Ziadé a écrit :
>> On Tue, Sep 30, 2008 at 10:42 AM, Nicolas Chauvat
>> <[EMAIL PROTECTED]> wrote:
>> > For example, if you require a minimal version of 1.4, you can
>> > t
On Tue, Sep 30, 2008 at 2:38 PM, zooko <[EMAIL PROTECTED]> wrote:
> On Sep 29, 2008, at 6:09 AM, Tarek Ziadé wrote:
>
>> Now, the question is, what would debian miss in here to install:
>>
>> http://www.python.org/dev/peps/pep-0345/
>
> It really seems to me that PEP-345's specification of depende
On Sep 29, 2008, at 6:09 AM, Tarek Ziadé wrote:
Now, the question is, what would debian miss in here to install:
http://www.python.org/dev/peps/pep-0345/
It really seems to me that PEP-345's specification of dependency
metadata is the wrong starting point.
There are not, to my knowledge,
Hello
In order to continue the effort started here. We are organizing a
distutils "PEP sprint" with people that works differently to deliver
Python applications.
http://wiki.python.org/moin/DistributeSprint_#1
Some Python developers from the Debian world and Scons specialist will
join. I'll brin
On Tue, Sep 30, 2008 at 10:42 AM, Nicolas Chauvat
<[EMAIL PROTECTED]> wrote:
> For example, if you require a minimal version of 1.4, you can
> translate this to a package version of 1.4; it is a bit hackish but
> will work if you handle epochs correctly. But if the package you
> depend on has a Pro
Hi,
On Mon, Sep 29, 2008 at 02:09:15PM +0200, Tarek Ziadé wrote:
> That is exactly what was brought in the other thread in distutils-SIG,
> providing the package metadata in a simple way for os-vendors, without
> having to deal with things like setup.py
>
> Then having third party applications th
58 matches
Mail list logo
