At 10:13 PM 9/16/2009 -0400, David Lyon wrote:
On Wed, 16 Sep 2009 22:01:20 -0400, P.J. Eby p...@telecommunity.com
wrote:
It's not the application's business what the installation directory
is;
Yes, but it very much is.
An application needs to know what directory it has been installed
At 12:41 PM 9/17/2009 +0200, Tarek Ziadé wrote:
Also, if I understand clearly the idea, I find it rather cryptic to
add conditions to each dependency
like what Sridhar has shown.
That's actually not how it would work; you simply put section
headings inside the extras_require field, rather
At 01:48 PM 9/19/2009 +0100, Kyle MacFarlane wrote:
The way setuptools (and thus buildout) does namespace packages
doesn't work with how Django looks for management commands. Django
only looks in the first package in the namespace on the system path
and ignores the rest.
If they use the
At 09:17 AM 9/20/2009 +0100, Kyle MacFarlane wrote:
2009/9/19 P.J. Eby p...@telecommunity.com
If they use the package's __path__ attribute, they'll find its
contents, whether someone is using pkgutil.extend_path, .pth files,
or setuptools. Â They don't have to support setuptools to support
At 10:26 PM 9/20/2009 -0400, David Lyon wrote:
Eh? It's *possible* to specify it in those places now, but
well-behaved packages never do.
Not on windows, outside of the c:\pythonXY directory.
Create a setup.cfg with an [install] section and you can make it
install wherever you tell it
At 10:15 PM 9/21/2009 +0200, Lennart Regebro wrote:
2009/9/21 Wolfgang Schnerring w...@gocept.com:
My favourite colour: use 2to3 as the prefix (consistency helps, I
think), like so:
2to3_enabled, 2to3_convert_doctests, 2to3_fixers, ...
That works. Maybe just 2to3_doctests?
Really? I
At 03:49 PM 10/3/2009 +0200, Tarek Ziadé wrote:
Notice that this has been fixed in Ubuntu already with a patched
version of setuptools
Is the patch or an equivalent already in the setuptools tracker? And
if not, can someone please post it there? Thanks.
At 07:25 AM 10/5/2009 -0700, K. Richard Pixley wrote:
How do I delete a package using easy_install?
http://peak.telecommunity.com/DevCenter/EasyInstall#uninstalling-packages
___
Distutils-SIG maillist - Distutils-SIG@python.org
At 04:57 PM 10/5/2009 +0200, Lennart Regebro wrote:
2009/10/5 Barry Warsaw ba...@python.org:
I apologize for my part in this, but moving forward I think that if it's
possible to patch and release a setuptools that works with Python 2.6.3
/and/ earlier Python 2.6.x's, then that should happen
At 06:53 PM 10/5/2009 +0200, Lennart Regebro wrote:
Possibly if you somehow
think it's the Distribute teams fault that a bugfix in Python ended up
breaking setuptools. If it would have been better not to fix that bug,
then the blame reasonably goes to the Python core developers, not the
At 07:53 PM 10/5/2009 +0200, Hanno Schlichting wrote:
If I understand the comments on this ticket correctly, Tarek has
changed distutils in a way so the last setuptools release continues
to work, correct?
Yes. And a very nice fix, done quite quickly. Thank you Tarek.
So based on the
At 11:29 AM 10/5/2009 -0700, K. Richard Pixley wrote:
P.J. Eby wrote:
At 07:25 AM 10/5/2009 -0700, K. Richard Pixley wrote:
How do I delete a package using easy_install?
http://peak.telecommunity.com/DevCenter/EasyInstall#uninstalling-packages
That doesn't remove a package. It simply removes
At 09:20 AM 10/6/2009 +0300, Alex Grönholm wrote:
P.J. Eby kirjoitti:
At 11:53 AM 10/5/2009 +0200, Lennart Regebro wrote:
2009/10/5 Jeff Rush j...@taupro.com:
Very unfortunate, as in, it should NOT have happened. And *especially*
without any announcement on python.org or mention
I've just updated the setuptools trunk and branch with a large number
of bug fixes, preparing to release 0.6c10. These fixes include fixes
for all the setuptools bugs currently marked in-progress or
testing on the setuptools bug tracker as of this moment, and I'd
like your help in ensuring
At 08:09 AM 10/12/2009 +, Reinout van Rees wrote:
OTOH, grumbl ... horrible breakage ... essential piece of infrastructure ...
allowed to persist I'm pretty grumpy right now.
Relax, take a deep breath, and then easy_install setuptools==dev or
setuptools==dev06. ;-)
It turned out
At 07:28 PM 10/12/2009 -0400, sstein...@gmail.com wrote:
we must uninstall Distribute completely get these fixes.
That's Distribute's doing, not mine. As I understand it, their
package includes a 'setuptools' package, and if it's on your
sys.path, then installing the new version of
At 01:31 PM 10/13/2009 -0400, Tres Seaver wrote:
Why?
Because the user might have, say, setuptools 0.6c8, and the package
relies on a bugfix in 0.6c9. Also, at some point, there will be an
0.7a1, with new features that some people might actually want to use.
(Some projects also actually
At 01:45 PM 10/13/2009 -0400, Tres Seaver wrote:
Reinout van Rees wrote:
On 2009-10-08, Ian Bicking i...@colorstudy.com wrote:
So after creating, say, version 0.3.1, I always mark a package
as 0.3.2dev.
But this is annoying, you might never create a version 0.3.2 (e.g., 0.4
might be the
At 02:51 PM 10/13/2009 -0400, Jim Fulton wrote:
Really the run-time
code needed to support namespace packages should be split out into a
separate package and eventually added to the standard library.
Are you volunteering? ;-)
Seriously, MvL's namespace package PEP (#382) already takes care
At 09:25 PM 10/13/2009 +0200, Tarek Ziadé wrote:
Notice that the current trunk of Distribute is now changing any 'setuptools'
requirement that is tiggered using Requirement.parse and resolve APIs into
a 'distribute' one.
Please note that this change will cause problems for people in the
At 09:53 PM 10/13/2009 +0200, Tarek Ziadé wrote:
2009/10/13 P.J. Eby p...@telecommunity.com:
At 09:25 PM 10/13/2009 +0200, Tarek Ziadé wrote:
Notice that the current trunk of Distribute is now changing any
'setuptools'
requirement that is tiggered using Requirement.parse and resolve APIs
At 06:46 PM 10/14/2009 +0200, kiorky wrote:
As i understood, NS.foo from setuptools can't be imported in NS.bar
from pkgutil
and vice versa.
Not so. The true implementation of nsp's is in __path__, which is
provided by Python's import libraries, not setuptools or pkgutil.
At 04:55 PM 10/14/2009 +0200, Lennart Regebro wrote:
2009/10/14 kiorky kio...@cryptelium.net:
That's not what said the PEP (IOW what i had understood of)
Oh, you don't *use* it the same way, no, but I assumed that the
internal mechanisms would be similar. Maybe I was wrong.
You can use as
At 02:32 PM 10/15/2009 +0200, Tarek Ziadé wrote:
That would make us happy, because we would be able to work and
continue if you are not available sometimes without the feeling
that we are locked, and that would give you the manpower you miss to
develop some of your idea.
So... you've explained
At 02:38 PM 10/15/2009 -0400, sstein...@gmail.com wrote:
that there are other people on the Distribute team who I'd
seriously consider as committers on setuptools or even as a chief
maintainer of the setuptools 0.6 line (if not more).
...asked me who those team members are
I'm asking. Who
At 10:46 AM 10/16/2009 -0400, sstein...@gmail.com wrote:
I don't know that I'd call what I saw designed. Complex, yes, but
design implies a plan and known direction, communicated by design
documents with tests that prove the code is working as expected.
This is not designed by any objective
After giving it some thought, I've decided to hold off on pushing out
the 0.6c10 release until Monday morning, since it's likely that some
people have scripts or build processes that run off of ez_setup SVN
or the latest PyPI version of setuptools... and who aren't aware the
release is coming
At 02:03 AM 10/17/2009 +, Reinout van Rees wrote:
I added the code that checks whether we're not requesting a 0.7-series
setuptools. So if a 0.7a1 setuptools comes out and someone requires it, it
will be installed: distribute won't fake a 0.7. And I added a similar check
in the (from the
The long-overdue setuptools 0.6c10 update is now available on PyPI, at:
http://pypi.python.org/setuptools/
Major updates and fixes include:
* Support for SVN 1.6 and Python 2.6
* Fix for the Python 2.6.3 build_ext API change
* Support for the most recent Sourceforge download link insanity
*
At 03:33 PM 10/19/2009 -0400, Barry Warsaw wrote:
Sorry for the lame-ass bug report, but my stack is really deep and I didn't
want this one to go unreported. I just tried 0.6c10 to see if it would fix a
problem I'm having. How fortunate that it hit Cheeseshop at just the right
time ;).
At 11:33 PM 10/19/2009 +0300, Alex Grönholm wrote:
P.J. Eby kirjoitti:
The long-overdue setuptools 0.6c10 update is now available on PyPI, at:
http://pypi.python.org/setuptools/
Major updates and fixes include:
* Support for SVN 1.6 and Python 2.6
* Fix for the Python 2.6.3 build_ext API
At 12:02 AM 10/20/2009 +0200, Patrice Neff wrote:
So the question would be: is there any way to avoid following any
dependency_links and/or find_links paths and only use the index_url?
Yes. See:
http://peak.telecommunity.com/DevCenter/EasyInstall#restricting-downloads-with-allow-hosts
which
At 02:05 AM 10/20/2009 +0100, Matthew Wilkes wrote:
On 2009-10-19, at 2055, P.J. Eby wrote:
Thanks; it's fixed and pushed back to PyPI.
With the same version number. What about the people who have already
installed your broke 0.6c10 that don't read this list?
They'll see an announcement
At 05:47 PM 10/22/2009 -0700, Kaelin Colclasure wrote:
Greetings,
I am attempting my first Python contribution and have run into a speed
bump getting a working setup.py using setuptools. Specifically, I
cannot coax it to install my package data files into the site-packages
directory. Here is a
At 09:58 PM 10/22/2009 -0700, Kaelin Colclasure wrote:
Restructuring as a package did indeed get things working as expected.
It's somewhat unfortunate that this is a requirement, as it made for a
lot of noise in my Mercurial repository and now most of my code is in
a module with the unhelpful
At 08:53 AM 10/23/2009 -0700, Kaelin Colclasure wrote:
On Oct 23, 2009, at 8:16 AM, P.J. Eby wrote:
At 09:58 PM 10/22/2009 -0700, Kaelin Colclasure wrote:
Restructuring as a package did indeed get things working as expected.
It's somewhat unfortunate that this is a requirement, as it made
At 12:01 AM 11/2/2009 +0100, Martin v. Löwis wrote:
It's actually Jeff Rush who is in charge of this tracker instance.
I can't change the setup without him agreeing.
So, Jeff, where else should the roundup instance for setuptools send
its notifications?
In over 1 year, there are now a grand
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
At 03:57 PM 11/7/2009 +0100, Andreas Jung wrote:
- supports too much different versioning schemas. Both
schema supported by setuptools and the one proposed
by Tarek in some PEP are totally over-engineered.
A simple and *enforced* versioning schema is what
I want to see.
- no more
At 03:13 PM 11/11/2009 +0100, Tarek Ziadé wrote:
But you call it with install in your example, meaning that is is
called at install time, right ?
Or it is just that you want to get the --prefix value finalized and
computed by the install
command. If it's the later, I guess you will be able to
At 12:36 AM 11/12/2009 -0600, Robert Kern wrote:
Sorry, I edited out the bit at the last minute where I explained
that it would be great to have a centralized option-managing object
such that any command can ask what options were set on any other
regardless of the dependencies between
At 02:59 PM 11/18/2009 -0500, Pavol Juhas wrote:
Hello,
I searched and read the recent discussions on the distutils-sig
list and I hope someone can help me with the following problem.
Is there a way to recover the prefix value inside pkgfoo/setup.py,
when it is installed as
easy_install
At 12:59 AM 11/19/2009 -0500, Pavol Juhas wrote:
As PJE mentioned, it is indeed
possible to walk the stack trace and rip out the original sys.argv
(and its '--prefix' element) from the easy_install main.
Technically, I meant it's possible to walk back until you find a
'self' that's a
At 04:40 PM 11/19/2009 +0100, Fabrizio Pollastri wrote:
the source structure is the following.
my_package_source_dir/
common_files
files_for_python
files_for_jython
It will be a maximum, if distutils let me to reach the following goals.
1. python/jython setup.py
At 07:55 PM 11/26/2009 +, Floris Bruynooghe wrote:
On Thu, Nov 26, 2009 at 01:08:34PM +0100, M.-A. Lemburg wrote:
Examples:
3.2.0a0.20091125
3.2.0a1
= 3.2.0_alpha_1
Frankly I find this confusing. I'm fine with 'alpha' being a synonym
for 'a' but the underscores just confuse things
At 10:32 AM 11/28/2009 +1100, Ben Finney wrote:
This is a red herring, AFAICT. It's been discussed already that
workflow is orthogonal to version comparison semantics. That is,
nothing about a workflow involving snapshots or dev versions etc.
implies that exceptional version keywords need to
At 12:26 PM 11/28/2009 +1100, Ben Finney wrote:
I think you're reading a proposal that I didn't write.
Are you not the person who's proposed using simple alphanumeric
strings for version comparison?
My understanding of PEP 386 is that it *isn't* about asking Python
developers to change how
At 10:50 AM 11/28/2009 +0100, Laura Creighton wrote:
But I think that it is the other way around ... what we want is a
timestamp. The algorithm is for guessing which version is ealier
in the absence of a timestamp.
You're assuming a process with no branches, where e.g. version 1.2 is
being
At 09:41 AM 11/28/2009 +0100, Tarek Ziadé wrote:
That's completely wrong, the proposal is a benefit for all of us,
because it standardizes something that is already being done.
You seem to have misunderstood me; I'm objecting to Ben Finney's
simple alphanumeric sort, not to PEP 386 in
At 08:11 PM 11/28/2009 +0100, M.-A. Lemburg wrote:
Tarek Ziadé wrote:
On Thu, Nov 26, 2009 at 1:08 PM, M.-A. Lemburg m...@egenix.com wrote:
Here's another take at a minimal change to the format which
includes the things we discussed, adds a few more aliases
for the post and dev markers and
At 09:15 PM 11/29/2009 +0100, Tarek Ziadé wrote:
2009/11/29 P.J. Eby p...@telecommunity.com:
[..]
WSGI and setuptools have been widely adopted in spite of their
technical and
ideological flaws, because they had good incentive engineering.
Or, in other words, because practicality beats
At 02:09 PM 11/30/2009 +, Ram Rachum wrote:
I've asked before about bundling Distribute. But now I ask, is it possible to
pull out the `pkg_resources` module from the Distribute folder and
bundle only
that with my project?
If your project is a standalone application with a completely
At 07:16 PM 11/30/2009 +0200, cool-RR wrote:
Well, that sort of sucks. And this is my motivation for bundling the
`pkg_resources` from Distribute. The last thing I want is having my
software fail for my users because of setuptools while I have
Distribute installed locally and can't see the bug
At 08:00 PM 11/30/2009 +0200, cool-RR wrote:
On Mon, Nov 30, 2009 at 7:57 PM, P.J. Eby
mailto:p...@telecommunity.comp...@telecommunity.com wrote:
At 02:09 PM 11/30/2009 +, Ram Rachum wrote:
I've asked before about bundling Distribute. But now I ask, is it possible to
pull out
At 08:10 PM 11/30/2009 +0100, Tarek Ziadé wrote:
2009/11/30 P.J. Eby p...@telecommunity.com:
At 07:16 PM 11/30/2009 +0200, cool-RR wrote:
Well, that sort of sucks. And this is my motivation for bundling the
`pkg_resources` from Distribute. The last thing I want is having
my software
fail
At 08:10 PM 11/30/2009 +0200, cool-RR wrote:
Now I'm confused. If that's true, what reason is there to use
Distribute's `pkg_resources` at all?
Unless there's some bug they've fixed in it that nobody has reported
here or on the setuptools bug tracker, there isn't any.
(And of course, if
At 08:59 PM 11/30/2009 +0200, cool-RR wrote:
Okay. But I don't use `require()`, the only thing I need from
`pkg_resources` is the ability to extract resources from folders. So
will there be any problem if I bundle it for that?
If that's all you're using, probably not. In any case, if that's
At 01:06 AM 12/3/2009 +0100, Andrew Dalke wrote:
Hi all,
I'm working with the Akara project. It contains a web server. The
server loads extensions from a special directory (let's say
$AKARA for now). An extension can register handlers for URLs. An
example extension might look like:
At 10:21 AM 12/3/2009 -0800, Sridhar Ratnakumar wrote:
Do you have anything particular in mind? What I did was a ``grep
^.*[a-zA-Z]\[`` in the requires.txt of (almost) all the packages in PyPI.
Do note that this won't tell you about end users' use of extras.
The main use case described in
At 08:25 PM 12/3/2009 +, Chris Withers wrote:
Hi All,
Say I have a package, mortar, that offers multiple extras options
for different data storage mechanisms, eg: sqlalchemy, zodb, simpledb
If I want to use this in a project and want both the sqlalchemy and
zodb backends, how do I spell
At 09:53 PM 12/3/2009 +0100, Attila Oláh wrote:
Wouldn't it require zope.component to be a namespace package? Extras
allw you to add extra files (subpackages) withot making the container
package a namespace-package, it seems to me.
No, they don't. Extras just cause a project to pull in
At 12:34 AM 12/5/2009 +0100, Andrew Dalke wrote:
I had some concerns about them. For one, all of the plugins define
out-word facing web services on our server. If the plugins can be
located in arbitrary locations inside of site-packages, how does the
administrator know which plugins will be
At 01:18 AM 12/5/2009 +0100, Andrew Dalke wrote:
It appears that pkg_resources does some caching, including using
linecache. I can't tell how well it would work if our pluging
packages were updated after the main server was running.
If you need to ensure that you get a fresh list of plugins
At 01:32 PM 12/9/2009 +0100, Rune Strand wrote:
Hi,
setuptools-0.6c11.win32-py2.6.exe will not install on Win 7 with
python 2.6.4 installed.
Dialog says: Python version 2.6 is required, which was not found in
the registry
That seems to be an indication that Python itself is not properly
At 04:10 PM 12/9/2009 -0700, Jeff Shell wrote:
I've been getting strange behavior with trying to use Buildout with
setuptools pinned to 0.6c11 on Mac OS X 10.6, with Python 2.4 built
from MacPorts. I'd constantly get the following error:
Getting distribution for 'zope.interface==3.5.2'.
At 05:17 PM 12/15/2009 +0100, Andrey Andreev wrote:
Hi Rune,
I had a similar issue on Windows Server 2008 R2. You are probably
running Win 7 (64bit). I ran procmon, and found out that the
installer is looking for the keys under:
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\PythonCore
At 06:10 PM 12/17/2009 +0200, Eemeli Kantola wrote:
Hi all,
I'm getting a crash in setuptools-0.6c11-py2.6 when trying to install
an egg directly from SVN sources. This happens both on OSX and Ubuntu,
versions:
Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) [GCC 4.2.1 (Apple
Inc. build
At 06:12 PM 12/18/2009 +0100, Aljoa MohoroviÄ wrote:
i've setup private pypi where i can upload some packages that are
not suitable for pypi.python.org. my package, let's call it myapp,
contains install_requires=['django',] but with that requirement i
can't install it.
At 08:44 PM 12/20/2009 +0100, Lukas Hetzenecker wrote:
I found a simpler way to do this - Is there any drawback if I try to solve
this problem using this way:
Yes. The --record option to the install command will be broken (due
to not including the directly-copied files).
(And that's only
At 10:24 AM 12/22/2009 +0900, David Cournapeau wrote:
1 Formally specifying the egg format (and versioning it !) - or is
egg format outside distribute goal ?
FYI: http://peak.telecommunity.com/DevCenter/EggFormats
___
Distutils-SIG maillist -
At 10:29 AM 1/7/2010 -0600, Brad Allen wrote:
On Thu, Jan 7, 2010 at 9:12 AM, John Gabriele jmg3...@gmail.com wrote:
On Thu, Jan 7, 2010 at 9:56 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Thu, Jan 7, 2010 at 3:52 PM, John Gabriele jmg3...@gmail.com wrote:
The only inconsistency, I think,
At 09:20 PM 1/7/2010 +0100, Martin v. Löwis wrote:
8614 *projects*, some of which have one or more *versions*, which in
turn may have one or more source or binary *distributions*.
Instead of version, I really like PyPI's term more: *releases*.
Not all versions are released versions, so I
At 11:00 AM 1/8/2010 -0600, Brad Allen wrote:
On Fri, Jan 8, 2010 at 10:29 AM, Lennart Regebro rege...@gmail.com wrote:
Just my 2 cents:
- The definitions that Tarek proposed it exactly how I already
use the words.
- I think Python Project Index is a better name than Python Package
Index.
At 09:13 AM 1/9/2010 -0600, Brad Allen wrote:
On Fri, Jan 8, 2010 at 11:44 AM, P.J. Eby p...@telecommunity.com wrote:
Yes, very much. I like 'parcel' better than 'project', partly because
it's not already overload with other contextual meanings.
This is just another example of the degree
At 05:32 PM 1/10/2010 +0100, Lennart Regebro wrote:
On Sun, Jan 10, 2010 at 16:24, Brad Allen bradallen...@gmail.com wrote:
I had thought 'egg' was just another distribution format, an
alternative to tarball, etc. But I have heard people at my local user
group use it to mean 'module
At 11:24 PM 1/11/2010 +0100, Ronny Pfannschmidt wrote:
Hi,
while toying with the entrypoint system, i repeatedly ran into the need
of having additional metadata prior to importing
In Plugins that only handle certain filetypes/extensions/mimetypes might
profit from the additional metadata
At 06:29 PM 1/23/2010 +0100, Tarek Ziadé wrote:
2010/1/23 P.J. Eby p...@telecommunity.com:
At 01:00 PM 1/23/2010 +0100, Tarek Ziadé wrote:
3 - dir_util, archive_util and file_util are going to be removed in
favor of calls to shutil.
By removed, do you simply mean that distutils will stop
At 04:05 PM 1/29/2010 -0500, Barry Warsaw wrote:
The important thing is to have exactly one place to set
the package's version number.
Put it in setup.py, then. If you absolutely must have a __version__
at runtime, use this to extract it from the installation metadata:
__version__ =
At 07:08 PM 1/30/2010 -0500, Barry Warsaw wrote:
On Jan 29, 2010, at 11:03 PM, Tarek Ziadé wrote:
Yes, that's how Jinja does already for example, using Setuptools's
pkg_resources :
__version__ = __import__('pkg_resources').get_distribution('Jinja2').version
And that's different yet again
At 05:53 PM 2/4/2010 +0100, Riccardo-Maria BIANCHI wrote:
Hi,
I have a package structured like this:
package/__init__.py
src/ __init__.py
mod1.py
share/__init__.py
mod2.py
Now I can import them as:
package.src.mod1
package.share.mod2
How can I use Distutils to be
At 01:55 AM 2/5/2010 +0100, Tarek Ziadé wrote:
I think it's still useful, because it points the root packages that
can be removed
safely without breaking the system -- even if leaving orphaned
packages behind.
Any opinion ?
I think it's a good idea to have a way to tell what packages were
At 07:37 AM 2/5/2010 -0600, Ron Adam wrote:
Because files from eggs can be installed in multiple directories,
and some of those are in arbitrary locations,
Scripts are the only things that get installed to other directories
from .eggs. Everything else is within the .egg file or directory.
At 01:39 PM 2/5/2010 -0500, Carl Meyer wrote:
What if RECORD allowed either absolute paths or paths relative to the
location of .egg-info, but nothing else? That would preserve the option
for application authors to make relocatable self-contained
installations, while keeping RECORD simple and
At 06:10 PM 2/5/2010 -0800, Sridhar Ratnakumar wrote:
On 2010-02-05, at 4:57 PM, P.J. Eby wrote:
At 04:49 PM 2/5/2010 -0800, Sridhar Ratnakumar wrote:
Do we have a real-world example for installing uninstallable
data files outside sys.prefix?
Scripts aren't always in sys.prefix,
Scripts
At 02:23 PM 2/16/2010 +0100, Manlio Perillo wrote:
Is it possible to declare a custom directory where some of the scripts
needs to be installed?
No. However, you can always create a script whose job is to symlink
your other scripts to the appropriate cron directory, and ask your
users to
At 04:37 PM 2/16/2010 +0100, Manlio Perillo wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
P.J. Eby ha scritto:
At 02:23 PM 2/16/2010 +0100, Manlio Perillo wrote:
Is it possible to declare a custom directory where some of the scripts
needs to be installed?
No. However, you can
At 09:11 PM 2/16/2010 +0100, Manlio Perillo wrote:
You are right, this is a singleton web application!
So, it will not be installed using pip or easy_install.
I have to decide if it is best to abuse setuptools plugin support, in
order to install system services (cron scripts, init.d script) or
At 01:34 AM 2/19/2010 +0100, Assem Chelli wrote:
Hi
how to change setup.py to include special filetypes and subdirectories
recursively in python eggs
Option 1: Put them under revision control using CVS, Subversion, or
any revision control system that has a setuptools plugin (in which
the include_package_data=True in your setup().
2010/2/19, P.J. Eby p...@telecommunity.com:
At 01:34 AM 2/19/2010 +0100, Assem Chelli wrote:
Hi
how to change setup.py to include special filetypes and subdirectories
recursively in python eggs
Option 1: Put them under revision control using CVS, Subversion
At 05:20 PM 2/22/2010 +0100, Jean Daniel wrote:
Hello, I am writing a pure python module called wordish, which is
similar to doctest in that it test snippets of code, parsed from an
rst article and produce a report. wordish is available on Pypi in
version 1.0 and the documentation is available
At 04:13 AM 2/21/2010 +0100, Daniel Niccoli wrote:
Hello Phillip,
if you install the x86-64 version of python, the windows installer
setuptools-0.6c11.win32-py2.6.exe does not find any Python
installation. I had to export the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Python, change it to
At 05:32 PM 2/23/2010 -0500, Tarek Ziadé wrote:
2/ the work done in 2.7 so far was following the usual deprecation
process for relocated
APIs or removed APIs, but nothing for misplaced import statements. We
did discuss this in the past and said it was fine this way.
Btw, imports from
At 06:05 PM 2/23/2010 -0500, Tarek Ziadé wrote:
Or do you mean that you consider the exception classes located in
Distutils to be a common need
for people that write setup.py scripts ?
A setup script may want to explicitly throw (or catch) distutils
errors, and having only one place to import
At 10:16 AM 2/26/2010 -0500, Olemis Lang wrote:
Well not as happily as I thought in first place. The fact is that
`setuptools` test command creates the runner by calling the class
specified in `test_runner` arg but supplies no parameters. In this
case I'd like to specify
At 11:19 AM 2/26/2010 -0500, Olemis Lang wrote:
On Fri, Feb 26, 2010 at 10:52 AM, P.J. Eby p...@telecommunity.com wrote:
At 10:16 AM 2/26/2010 -0500, Olemis Lang wrote:
Well not as happily as I thought in first place. The fact is that
`setuptools` test command creates the runner by calling
, a module, TestCase
subclass, etc.
You are probably thinking of the test_runner option, not test_suite.
test command performs test discovery (as a last recourse AFAICR, /me
cc-ing to P.J. Eby because probably he has further updates ;o) using a
loader: setuptools.comand.test.xxx
Setuptools
At 10:03 PM 2/28/2010 +0100, Jean Daniel wrote:
Can this be simpler?
Yes. Don't install docs with your package. People who want them
installed locally can just download your source install or use easy_install -e.
Also, if your module is popular enough that people make Linux system
At 10:39 PM 2/28/2010 +, Michael Foord wrote:
On 28 February 2010 22:14, P.J. Eby
mailto:p...@telecommunity.comp...@telecommunity.com wrote:
At 10:03 PM 2/28/2010 +0100, Jean Daniel wrote:
Can this be simpler?
Yes. Don't install docs with your package. People who want them
installed
At 02:57 PM 3/9/2010 -0500, hari jayaram wrote:
Hi
I am installing setuptools using the --prefix option it complains
the directory does not exist even though it does. The install works
however when I use the --instal-dir option as it recommends.
macbook-pro-17:~ hari$ sudo sh
At 03:03 PM 3/9/2010 -0600, Brad Allen wrote:
Today I was informed of an issue in which buildout (with the latest
setuptools) is not resolving version numbers properly, causing the
wrong package to be selected in some cases. The cause identified was
having '_' in the package name.
I suspect
201 - 300 of 503 matches
Mail list logo
