Hello,
I would like to bundle Distribute with my project
so that I could use it without making my users
install it. (I like to keep things as simple as
possible for my users.)
Is it possible? I thought of just copying the
setuptools folder from the source distribution
into a package in my
Hi,
While reading the PEP I noticed that there seems to be no straightforward
to specify the package release versions.
egginfo_dirname('python-ldap', '2.3.10')
'python_ldap-2.3.10.egg-info'
Consider the following PyPM package file name:
python-ldap-2.3.10_linux-x86_2.6_2.pypm
Here
On Thu, Nov 5, 2009 at 8:58 PM, Ram Rachum cool...@cool-rr.com wrote:
Hello,
I would like to bundle Distribute with my project
so that I could use it without making my users
install it. (I like to keep things as simple as
possible for my users.)
Is it possible? I thought of just copying
Tarek Ziadé ziade.tarek at gmail.com writes:
On Thu, Nov 5, 2009 at 8:58 PM, Ram Rachum cool-rr at cool-rr.com wrote:
Pruned
Does it make sense? Will it work? Anything else I
should keep in mind?
Hello,
It is possible to bundle, but the best strategy depends on what you are
doing
On Thu, Nov 5, 2009 at 9:31 PM, Sridhar Ratnakumar
sridh...@activestate.com wrote:
Hi,
While reading the PEP I noticed that there seems to be no straightforward to
specify the package release versions.
egginfo_dirname('python-ldap', '2.3.10')
'python_ldap-2.3.10.egg-info'
Consider the
2009/11/5 Ram Rachum cool...@cool-rr.com:
I'll be using it my setup.py, and I've also heard about pkg_resources and I'll
want to use that. And maybe there will be more interesting things in
Distribute
that I'll want to use. What do you suggest I should do?
In that case you need it installed,
On Thu, Nov 5, 2009 at 9:53 PM, Ram Rachum cool...@cool-rr.com wrote:
[cut]
I'll be using it my setup.py, and I've also heard about pkg_resources and I'll
want to use that. And maybe there will be more interesting things in
Distribute
that I'll want to use. What do you suggest I should do?
On 2009-11-05 15:03 PM, Tarek Ziadé wrote:
On Thu, Nov 5, 2009 at 9:31 PM, Sridhar Ratnakumar
sridh...@activestate.com wrote:
Hi,
While reading the PEP I noticed that there seems to be no straightforward to
specify the package release versions.
egginfo_dirname('python-ldap', '2.3.10')
Tarek Ziadé ziade.tarek at gmail.com writes:
There's a trick to use it without installing it :
- add the distribute_setup.py script besides your setup.py script
- call the use_setuptools API in setup.py, so distribute gets
downloaded then added in the path
(see the documentation for
On Thu, Nov 5, 2009 at 10:31 PM, Sridhar Ratnakumar
sridh...@activestate.com wrote:
Because python-ldap may release a similar version in future. We don't have
to cause collisions. This is why the release version is not part of package
version in the *.pypm filename.
Ok
I actually now think
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tarek Ziadé wrote:
In that case, an arbitrary file that gets installed in the .egg-info/
directory, that you can read back when needed through the PEP 376
pkgutil new API, seem to be a good idea.
PEP 376 doesn't include a pkgutil API for reading
On Thu, Nov 5, 2009 at 10:31 PM, Robert Kern robert.k...@gmail.com wrote:
[..]
Generally speaking, it is desirable to distinguish between the upstream
package's version and the build number rather than munging them together.
You never know when the upstream package will decide that they need to
2009/11/5 Ram Rachum cool...@cool-rr.com:
Which leads me to my next
point: When creating a binary with Distribute, will it install Distribute
automatically on the user's computer?
1. No.
2. You should only create binary releases if your module contains
C-code and then only for Windows.
--
On Thu, 05 Nov 2009 14:14:19 -0800, Tarek Ziadé ziade.ta...@gmail.com
wrote:
I actually now think that storing the release number inside the
.egg-info/
directory may be a better idea. Like:
$ cat python_ldap-2.3.10.egg-info/pypm.txt
release: 2
$
What do you think?
In that case, an
On Thu, Nov 5, 2009 at 11:39 PM, Sridhar Ratnakumar
sridh...@activestate.com wrote:
[..]
Since release numbers are specific to the installer (and repository), how
about having it in the .egg-info/INSTALLER file?
$ cat .egg-info/INSTALLER
name: PyPM
[package]
release: 2
url:
Lennart Regebro regebro at gmail.com writes:
2. You should only create binary releases if your module contains
C-code and then only for Windows.
Why only if there's C code? I personally find it more convenient to install
binaries than from source.
2009/11/5 Ram Rachum cool...@cool-rr.com:
Why only if there's C code?
Because in general you want to compile the code on the system when
it's Linux or osx etc. It works better, and you don't have to provide
both 32bit and 64 bit versions and yadayada.
I personally find it more convenient to
On Thu, 05 Nov 2009 14:50:58 -0800, Lennart Regebro rege...@gmail.com
wrote:
I personally find it more convenient to install binaries than from
source.
Why?
1. Not having to deal build errors (due to missing libs or corrupt lib
installations)
2. Not having to have a compiler suite
Lennart Regebro regebro at gmail.com writes:
2009/11/5 Ram Rachum cool-rr at cool-rr.com:
Why only if there's C code?
Because in general you want to compile the code on the system when
it's Linux or osx etc. It works better, and you don't have to provide
both 32bit and 64 bit versions
On Fri, Nov 6, 2009 at 12:39 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Thu, Nov 5, 2009 at 11:32 PM, Lennart Regebro rege...@gmail.com
wrote:
2009/11/5 Ram Rachum cool...@cool-rr.com:
Which leads me to my next
point: When creating a binary with Distribute, will it install
2009/11/5 Sridhar Ratnakumar sridh...@activestate.com:
1. Not having to deal build errors (due to missing libs or corrupt lib
installations)
Then you need to compile the libs statically, and then you open up
another can of worms with incompatibilities there.
2. Not having to have a compiler
At 11:00 PM 11/5/2009 +, Ram Rachum wrote:
Lennart Regebro regebro at gmail.com writes:
2009/11/5 Ram Rachum cool-rr at cool-rr.com:
Why only if there's C code?
Because in general you want to compile the code on the system when
it's Linux or osx etc. It works better, and you don't
2009/11/6 P.J. Eby p...@telecommunity.com:
Not for people using easy_install or its derivatives (like pip and
buildout). easy_install-based tools work as easily with source as binaries.
Right. And untaring and running setup.py install is not exactly a
massive amount of work either. :)
--
Lennart Regebro rege...@gmail.com writes:
2009/11/6 P.J. Eby p...@telecommunity.com:
Not for people using easy_install or its derivatives (like pip and
buildout). easy_install-based tools work as easily with source as
binaries.
“binary package” != “setuptools egg”. At least, I didn't
2009/11/6 Ben Finney ben+pyt...@benfinney.id.au:
Time spent installing is only part of the cost. Neither of thosr options
cooperate with the operating system's *own* package management.
Well, do to THAT you have to make packages for that systems own
package management, and that's a completely
25 matches
Mail list logo
