On Wed, Apr 22, 2015 at 5:20 PM, Robert Collins
robe...@robertcollins.net wrote:
Ah, ok so I think this is the crux - I'm arguing that Python version
isn't a big enough check. Because anything installed with a current
version of setuptools, or any wheel built likewise, is going to not
have
On Fri, Sep 12, 2014 at 3:55 PM, Erik Bray erik.m.b...@gmail.com wrote:
Unfortunately there are some dark corners of setuptools I've
encountered where namespace packages don't work properly during
installation *unless* they were installed in the old-fashioned
setuptools way. I'll have to see
On Fri, Jun 6, 2014 at 10:25 AM, Donald Stufft don...@stufft.io wrote:
I expected more people to move to safe external vs staying with the unsafe
external.
Is there a tool that makes this *easy*? I'm not aware of one.
(Ideally, something like a replacement for setup.py upload that generates
On Mon, Apr 7, 2014 at 4:03 PM, Daniel Holth dho...@gmail.com wrote:
OK, it does in fact work that way; empty-string-before-colon specifies
a default requirement with a marker.
Parses out to the following _dep_map with 'None' representing 'not an
extra dependency':
{None:
On Wed, Mar 26, 2014 at 11:55 PM, Eric Snow ericsnowcurren...@gmail.comwrote:
In 3.4 it's called _NamespaceLoader, but in 3.3 it's NamespaceLoader.
ducks
Ouch. That is going to be a really *long* bit of code. Not like it isn't
already, though.
By available on the platform do you mean
On Wed, Mar 26, 2014 at 11:29 PM, Daniel Holth dho...@gmail.com wrote:
How do I specify a conditional (marker-guarded) non-extra dependency
in setuptools? The syntax for a conditional extra dependency is
currently:
extras_require = {
ssl:sys_platform=='win32': wincertstore==0.2,
On Mon, Mar 24, 2014 at 6:09 PM, Barry Warsaw ba...@python.org wrote:
On Mar 24, 2014, at 05:53 PM, Donald Stufft wrote:
See also https://github.com/pypa/pip/issues/3
Hah, yeah. I didn't realize --single-version-externally-managed is
implied by
--root, and in fact our Debian build scripts
On Tue, Mar 25, 2014 at 3:50 PM, Barry Warsaw ba...@python.org wrote:
On Mar 25, 2014, at 03:35 PM, PJ Eby wrote:
I think the correct fix would be to change the nspkg.pth magic to check
for
PEP 420 support, but unfortunately it seems we may have to use version
checking: on rereading PEP 420
On Mon, Mar 24, 2014 at 8:46 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 24 March 2014 20:53, Martin v. Löwis mar...@v.loewis.de wrote:
Both problems would be resolved by setting the tracker to read-only;
shutting it down is actually not necessary (although it would slightly
reduce our
On Sun, Mar 23, 2014 at 4:55 AM, Martin v. Löwis mar...@v.loewis.dewrote:
We are still hosting a roundup installation for setuptools,
at http://bugs.python.org/setuptools/.
Is this still needed? If not: what should we do with it?
I think probably the remaining issues need to be moved to
23, 2014 at 2:00 PM, Martin v. Löwis mar...@v.loewis.dewrote:
Am 23.03.14 18:30, schrieb PJ Eby:
On Sun, Mar 23, 2014 at 4:55 AM, Martin v. Löwis mar...@v.loewis.de
mailto:mar...@v.loewis.de wrote:
We are still hosting a roundup installation for setuptools,
at http
On Sat, Mar 1, 2014 at 4:47 PM, Jim Fulton j...@zope.com wrote:
On Thu, Feb 27, 2014 at 6:49 AM, Piotr Dobrogost
p...@google-groups-2014.dobrogost.net wrote:
Hi!
I've seen people putting 'setuptools' in 'install_requires' in
setup.py starting with import from setuptools like this:
On Wed, Feb 12, 2014 at 11:11 AM, Sebastien Douche sdou...@gmail.com wrote:
On Wed, Feb 12, 2014 at 5:09 AM, Jason R. Coombs jar...@jaraco.com wrote:
Hi Jason
This backward-incompatible release contains the changes detailed in the
CHANGES.txt file:
Issue #148: When building (bdist_egg),
On Tue, Jan 7, 2014 at 4:07 AM, Maciej (Matchek) Bliziński
mac...@opencsw.org wrote:
2013/10/1 Maciej (Matchek) Bliziński mac...@opencsw.org
Hello setuptools developers,
I'm attempting to package the newest setuptools version (1.1.6)
on Solaris 9 and 10. One of the limitations of the Solaris
On Wed, Jan 1, 2014 at 9:39 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 1 Jan 2014 10:33, PJ Eby p...@telecommunity.com wrote:
I have only been skimming these so far, will comment more later, but I
just want to mention that for standard extensions, what is the
rationale for not defining e.g
On Sat, Dec 21, 2013 at 9:46 AM, Nick Coghlan ncogh...@gmail.com wrote:
I've just published the first draft of the metadata 2.0 spec that
moves all of the fields that aren't part of the core metadata or
potentially needed for dependency resolution out to a separate
standard metadata extensions
On Tue, Nov 19, 2013 at 6:22 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 19 November 2013 15:09, PJ Eby p...@telecommunity.com wrote:
On Sun, Nov 17, 2013 at 8:44 AM, Nick Coghlan ncogh...@gmail.com wrote:
More accurately, it appears setuptools *does* support PEP 345 style
environment
On Tue, Nov 19, 2013 at 5:24 PM, Nick Coghlan ncogh...@gmail.com wrote:
Perhaps it would be worth breaking the environment markers out as their own
PEP?
As I said back then, I think *everything* in PEP 426 is worth breaking
out into its own PEP. ;-)
Less jokingly, I think that the scope of
On Sun, Nov 17, 2013 at 8:44 AM, Nick Coghlan ncogh...@gmail.com wrote:
More accurately, it appears setuptools *does* support PEP 345 style
environment markers, it just isn't documented at
http://pythonhosted.org/setuptools/setuptools.html#declaring-dependencies
*sigh*
That's because it's
On Mon, Oct 28, 2013 at 4:29 AM, Martin Fiers
martin.fi...@intec.ugent.be wrote:
I guess we'll have to
rename them manually after the setup() function, unless there's a way to
'force' setup() to 'think' it has compiled extensions in them?
You could include a dummy extension that does nothing,
On Tue, Oct 15, 2013 at 8:07 AM, Martin Fiers
martin.fi...@intec.ugent.be wrote:
So the platform argument now is
self.distribution.has_ext_modules() and self.plat_name
Shouldn't it just be
self.plat_name
?
No. The platform name is only included if the distribution has
extension modules,
On Wed, Oct 2, 2013 at 10:57 PM, Donald Stufft don...@stufft.io wrote:
I've recently deployed the current Warehouse code. So far the
simple API has been implemented and it would be great if
people could point their installers to it and report back to me
if they run into any problems.
The
On Tue, Oct 1, 2013 at 1:51 PM, Daniel Holth dho...@gmail.com wrote:
pkg_resources only finds distributions inside .egg and inside sys.path
entries that are filesystem directories.
Actually it looks in zipfiles (or subdirectory paths thereof) or
filesystem directories, and can spot zipfile
On Tue, Oct 1, 2013 at 5:11 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 1 October 2013 21:32, PJ Eby p...@telecommunity.com wrote:
On Tue, Oct 1, 2013 at 1:51 PM, Daniel Holth dho...@gmail.com wrote:
pkg_resources only finds distributions inside .egg and inside sys.path
entries
On Tue, Oct 1, 2013 at 7:10 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 2 Oct 2013 07:12, Paul Moore p.f.mo...@gmail.com wrote:
On 1 October 2013 21:32, PJ Eby p...@telecommunity.com wrote:
On Tue, Oct 1, 2013 at 1:51 PM, Daniel Holth dho...@gmail.com wrote:
pkg_resources only finds
On Mon, Sep 30, 2013 at 1:55 PM, Marcus Smith qwc...@gmail.com wrote:
so, take a case like so pytest-xdist-dev.tar.gz (or any sdist with - in
the project name, and a version starting with a string)
I think it's like so:
- pkg_resources.Distribution.from_location will treat xdist-dev as the
On Mon, Sep 30, 2013 at 4:11 PM, Marcus Smith qwc...@gmail.com wrote:
The setuptools.package_index API, however, *does* support parsing
sdist names, it's just that it generates a *list* of possibilities,
oh, ok, setuptools.package_index.distros_for_url
Thus, tools using this API can
On Mon, Sep 30, 2013 at 6:06 PM, Marcus Smith qwc...@gmail.com wrote:
how will context decide between the version being dev or xdist-dev?
By whether you asked to install pytest-xdist or pytest, and by
whether dev or xdist-dev match your version requirements. In
practice this tends to only
On Sun, Sep 22, 2013 at 9:01 AM, Paul G. paul.l...@isrcomputing.com wrote:
1. What format should I use in my README.txt file for my package's content
to be displayed on its package page?
It's not the README file; it's the package's long_description
keyword, as specified in your setup.py setup()
On Fri, Sep 20, 2013 at 8:15 AM, Jim Fulton j...@zope.com wrote:
It appears that MANIFEST.in is ignored if setuptools recognizes your
VCS.
Not in setuptools 0.6 it isn't. However, it's really only useful for
*adding* files not picked up by revision control; it can't *remove*
files found by
On Wed, Sep 18, 2013 at 5:07 PM, Benjamin Root ben.v.r...@gmail.com wrote:
In creating a source distribution, I have found a disparity between the
behaviors of distutils and setuptools with respect to package_data. As of
python Issue 2279: http://bugs.python.org/issue2279, entries listed in
On Thu, Sep 12, 2013 at 2:14 PM, Daniel Holth dho...@gmail.com wrote:
I'm suggesting it might be a bug in pkg_resources, or it might be
something pkg_resources can already do, if pip.zip is added to
PYTHONPATH while executing setup.py in a subprocess.
pkg_resources can detect subdirectories in
On Mon, Sep 9, 2013 at 10:54 AM, Paul Moore p.f.mo...@gmail.com wrote:
Is the spec at
http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api
still the definitive version of what must be provided for a local PyPI
index (for use by something like pip)? Or is there a more up to
On Mon, Aug 26, 2013 at 2:25 PM, bharath ravi kumar
reachb...@outlook.com wrote:
Carl, Eby,
Thanks for taking time to suggest various alternatives. Considering that the
deployment hosts are identical in every as[ect, the approach of moving
virtualenv's with packages pip-installed at build
On Tue, Aug 27, 2013 at 3:01 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 27 August 2013 00:15, PJ Eby p...@telecommunity.com wrote:
None of these things is wrong. It is *spreading* FUD (and in particular,
doing so cynically to undermine a proposal) that is wrong, and I hope I
didn't do
On Mon, Aug 26, 2013 at 5:20 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 25 August 2013 23:14, PJ Eby p...@telecommunity.com wrote:
Thus, you don't have to know you have multiple versions installed; it
can trivially happen by way of dependencies you aren't paying
attention to. The more
On Mon, Aug 26, 2013 at 11:15 AM, Donald Stufft don...@stufft.io wrote:
There is always a cost. In this case mostly in complexity and start up time.
As you mentioned originally the cost to multi version support was the need
to use a require() function and when people complained about that you
On Mon, Aug 26, 2013 at 5:59 PM, Donald Stufft don...@stufft.io wrote:
I think you're confused. The only comments I see in this thread are people
doing
due diligence to ensure that Nick's proposal *didn't* include the parts of
setuptools
that we felt were incurring a cost against people not
On Sun, Aug 25, 2013 at 12:58 PM, Jim Fulton j...@zope.com wrote:
On Sun, Aug 25, 2013 at 3:06 AM, Nick Coghlan ncogh...@gmail.com wrote:
The clumsiness of the __main__.__requires__ workaround aside, the main
advantage this offers is that it *should* result in a relatively
straightforward
On Sun, Aug 25, 2013 at 4:32 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 25 August 2013 20:53, PJ Eby p...@telecommunity.com wrote:
FWIW, I would also note that if you use easy_install to install
anything, you are quite possibly using multi-version installs without
realizing
On Fri, Aug 23, 2013 at 6:45 AM, bharath ravi kumar
reachb...@outlook.com wrote:
I'm looking to package an application with all its dependencies for
deployment on multiple hosts. I'd like to ensure that there is no
compilation or setup step before starting the application in production. An
On Wed, Aug 21, 2013 at 9:24 AM, Donald Stufft don...@stufft.io wrote:
An example is the wsgiref from the standard library.
It's an example, alright, but not for your side. ;-) The wsgiref
library doesn't just implement the spec, it implements a ton of
utility classes for use with the spec.
On Tue, Aug 20, 2013 at 12:39 PM, Thomas Heller thel...@ctypes.org wrote:
Ok, now I understand. But the zipfile could contain a loader-module
for each extension which does something like this (this example extracts
and loads 'bz2.pyd'):
...
(py2exe for Python 3, which is work in progress,
On Fri, Aug 16, 2013 at 6:21 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
PJ Eby pje at telecommunity.com writes:
I guess I didn't explain it very well, because that's roughly what I
meant: a single namespace for all extensions, structured as a
mapping from group names to submappings whose
On Fri, Aug 16, 2013 at 8:04 AM, Nick Coghlan ncogh...@gmail.com wrote:
Concrete extension use cases I have in mind that don't fit in the
exports/entry-point data model:
- the mapping of prebuilt executable names to wheel contents
- platform specific external dependencies and other hints for
On Thu, Aug 15, 2013 at 9:21 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 15 Aug 2013 00:39, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
PJ Eby pje at telecommunity.com writes:
The build system *should* reserve at least one (subdivisible)
namespace for itself, and use that mechanism
On Thu, Aug 15, 2013 at 7:16 PM, Nick Coghlan ncogh...@gmail.com wrote:
But if we're only going to validate it via hooks, why not have the mapping
of names to export specifiers just be a recommended convention for
extensions rather than a separate exports field?
I guess I didn't explain it
On Wed, Aug 14, 2013 at 7:34 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Jason R. Coombs jaraco at jaraco.com writes:
This means that instead of installing, for example:
Scripts\my-command.exe
Scripts\my-command-script.py
Scripts\my-command.exe.manifest
Just to muddy the waters
On Wed, Aug 14, 2013 at 9:58 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
IIUC PEP 441 is about tooling to create archives; don't we just need a
Python-compatible .zip (i.e. with a __main__.py)?
I meant that it has a #! line before the zip part, so that the
launcher knows what Python to
On Wed, Aug 14, 2013 at 11:36 AM, Nick Coghlan ncogh...@gmail.com wrote:
* group - name of the export group to hook
* preupdate - export to call prior to installing/updating/removing a
distribution that exports this export group
* postupdate - export to call after installing/updating/removing
On Wed, Aug 14, 2013 at 3:14 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 14 August 2013 14:00, PJ Eby p...@telecommunity.com wrote:
On Wed, Aug 14, 2013 at 11:36 AM, Nick Coghlan ncogh...@gmail.com wrote:
* group - name of the export group to hook
* preupdate - export to call prior
On Wed, Aug 14, 2013 at 2:14 PM, Paul Moore p.f.mo...@gmail.com wrote:
.pyw files can be imported as modules, just like .py,
Darn. Okay, so another extension *is* needed if you want to be able
to make non-console apps runnable-but-not-importable. IIUC it should
by '.pywa' rather than '.pya',
On Tue, Aug 13, 2013 at 8:54 AM, Jason R. Coombs jar...@jaraco.com wrote:
1. Renames, deletes, and other actions must be synchronized.
Why are you manually deleting or altering executables? Why are you
renaming them at all?
I've been using .exe wrappers since they were written, and have never
On Tue, Aug 13, 2013 at 12:33 PM, Paul Moore p.f.mo...@gmail.com wrote:
This works, but is an ugly, fragile workaround. It's *not* a huge problem,
it's just how executables work on Windows, and all installers have to deal
with this dance (it's why a lot of things need a reboot to complete
On Mon, Aug 12, 2013 at 7:33 AM, Nick Coghlan ncogh...@gmail.com wrote:
Having pys and pyz for executable, but not importable (source and zip
archive forms) could be quite clean. In effect, the pys extension would
bring windows to parity with *nix, where no extension at all has
traditionally
On Mon, Aug 12, 2013 at 10:32 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 12 August 2013 14:01, PJ Eby p...@telecommunity.com wrote:
As far as zipped Python applications are concerned (pyz), these can be
created by just using a pys file containing a #! line prepended to the zip
file
On Mon, Aug 12, 2013 at 2:14 PM, Jason R. Coombs jar...@jaraco.com wrote:
-Original Message-
From: Distutils-SIG [mailto:distutils-sig-
bounces+jaraco=jaraco@python.org] On Behalf Of PJ Eby
Sent: Monday, 12 August, 2013 11:22
On Mon, Aug 12, 2013 at 10:32 AM, Paul Moore p.f.mo
On Mon, Aug 12, 2013 at 4:04 PM, Paul Moore p.f.mo...@gmail.com wrote:
I would still like to see the standard be registered .pye (I'm happy with a
bikeshed of this colour) and .pwe extensions which are added to PATHEXT and
As long as we're discussing bikeshed colors, I'd like to
counterpropose
On Mon, Aug 12, 2013 at 4:29 PM, Donald Stufft don...@stufft.io wrote:
Hopefully this all will solve this problem, as it is right now if you use
setuptools entry points then Wheels erroneously pretend to be platform
agnostic.
IMO it's okay to give up having ready-to-use scripts in a
On Sun, Aug 11, 2013 at 10:38 AM, Jason R. Coombs jar...@jaraco.com wrote:
In Setuptools 1.0 (currently in beta), I've added an experimental, opt-in
feature to install pure Python launcher scripts on Windows instead of
installing a launcher executable for each script, with the intention that
On Sun, Aug 11, 2013 at 12:17 PM, PJ Eby p...@telecommunity.com wrote:
May I suggest an option 5 instead? Use the new .pyz (or .pyzw for
non-console apps) as a zipped Python application. .pyz files aren't
importable, but *are* executable. That's basically all that's needed
to prevent
On Sun, Aug 11, 2013 at 1:58 PM, Jason R. Coombs jar...@jaraco.com wrote:
This sounds like a suitable idea, but as you mention in a subsequent
message, this format has issues with sys.path assumptions as well.
Meh. It's basically, a one-line fix in the __main__.py, i.e.:
import
On Sun, Aug 11, 2013 at 7:31 PM, Jason R. Coombs jar...@jaraco.com wrote:
-Original Message-
From: Nick Coghlan [mailto:ncogh...@gmail.com]
Sent: Sunday, 11 August, 2013 17:14
We actually have a proposal on import-sig to allow module specific import
path manipulation (including the
On Fri, Aug 9, 2013 at 5:41 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 10 August 2013 04:06, PJ Eby p...@telecommunity.com wrote:
Probably a better way would be to change the version resolution
algorithm to be less greedy, and simply rule out unacceptable
versions as the process goes along
On Fri, Aug 9, 2013 at 8:04 AM, Jess Austin jess.aus...@gmail.com wrote:
hi,
I recently suggested that the gv package be added to PyPI. This is a
close-to-C Graphviz port distributed by the Graphviz graph visualization
project. They currently distribute this package in source, and in rpms,
On Fri, Aug 9, 2013 at 9:04 AM, Townsend, Scott E. (GRC-RTM0)[Vantage
Partners, LLC] scott.e.towns...@nasa.gov wrote:
That does indeed fix this problem, but requiring an egg writer to
interrogate all dependent packages (and their dependent packagesŠ) and
then hoist the dependencies up won't be
On Thu, Aug 8, 2013 at 3:19 PM, Townsend, Scott E. (GRC-RTM0)[Vantage
Partners, LLC] scott.e.towns...@nasa.gov wrote:
During easy_install of an egg where two versions of pyparsing were available
(1.5.2 and 1.5.6), a VersionConflict was raised:
pkg_resources.VersionConflict: (pyparsing 1.5.6
Hi. Not sure who this should go to, but it would be really good if we
could get a prominent notice on the old setuptools tracker (at
bugs.python.org), specifically on the issue creation screen, to inform
people that this tracker is only for setuptools 0.6, and that issues
for later versions
On Mon, Aug 5, 2013 at 11:10 AM, Nick Coghlan ncogh...@gmail.com wrote:
I filed the request on the metatracker:
http://psf.upfronthosting.co.za/roundup/meta/issue522
Thanks! That should keep me from having to keep telling people their
princess is in another castle. ;-)
On Sat, Aug 3, 2013 at 1:07 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
Just pushed these changes. I'm happy to leave the PEP alone for a
while now,
Thanks for doing these updates. Can I suggest the following corrections?
1. In the section
On Fri, Aug 2, 2013 at 11:27 AM, Nick Coghlan ncogh...@gmail.com wrote:
I pushed a version of PEP 426 with an initial sketch of an entry
points replacement design: http://hg.python.org/peps/rev/ea3d93e40e02
To give it a sensible home in the PEP, I ended up defining modules
and namespaces
On Tue, Jul 30, 2013 at 4:58 PM, Donald Stufft don...@stufft.io wrote:
Hrm.
So I hear what you're saying and part of the problem is likely due to the
history
of where I tried to get a change through and then felt like all I was getting
was
stop energy and people wanting to keep the status
On Tue, Jul 30, 2013 at 4:14 AM, Donald Stufft don...@stufft.io wrote:
Heh, I'm pretty good at getting yelled at :)
Nick is also pretty good at making people feel like he both knows and
*cares* about their breakage, and isn't just dismissing their concerns
as trivial or unimportant. Breakage
On Tue, Jul 30, 2013 at 2:04 PM, Donald Stufft don...@stufft.io wrote:
On Jul 30, 2013, at 1:13 PM, PJ Eby p...@telecommunity.com wrote:
On Tue, Jul 30, 2013 at 4:14 AM, Donald Stufft don...@stufft.io wrote:
Heh, I'm pretty good at getting yelled at :)
Nick is also pretty good at making
On Fri, Jul 26, 2013 at 12:25 PM, Donald Stufft don...@stufft.io wrote:
Additionally there is no security list from setuptools versions earlier than
0.7.
Not true, actually. Setuptools 0.6 dev releases supported SSL
verification since mid-May, but don't support any hashes besides MD5.
Anybody
On Fri, Jul 26, 2013 at 3:14 PM, Donald Stufft don...@stufft.io wrote:
Does the hashlib backport I added to
setuptools 0.9 for Python 2.4 work on 2.3? It's a pure python
implementation of hashlib.
Ah, didn't know about that! I can't imagine what problems there would
be; not much changed in
On Sat, Jul 20, 2013 at 10:54 PM, Nick Coghlan ncogh...@gmail.com wrote:
Extras should just be a way to ask are these optional dependencies present
on this system?, without needing to worry about how they got there.
Technically, they are a way to ask can you get this for me?, since
On Sun, Jul 21, 2013 at 6:44 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 22 Jul 2013 01:46, PJ Eby p...@telecommunity.com wrote:
Now that I'm thinking about it some more, one of the motivating use
cases for extras in entry points was startup performance in
plugin-heavy GUI applications
On Sat, Jul 20, 2013 at 8:08 PM, Nick Coghlan ncogh...@gmail.com wrote:
I see it as more useful for making an executable optional by defining a
cli extra. If your project just gets installed as a dependency, no wrapper
would get generated.
Only if you went pip install myproject[cli] (or
On Fri, Jul 19, 2013 at 9:10 AM, Nick Coghlan ncogh...@gmail.com wrote:
Right, I think the reasonable near term solutions are for pip to either:
1. generate zc.buildout style wrappers with absolute paths to avoid
the implied runtime dependency
2. interpret use of script entry points as an
On Fri, Jul 19, 2013 at 2:09 PM, Joe Gordon joe.gord...@gmail.com wrote:
When I try importing pkg_resources in our development environment it is very
slow:
Use zc.buildout to install the application you're invoking, and then
it won't need to import pkg_resources. (Unless the actual app uses
On Thu, Jul 18, 2013 at 1:50 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Daniel Holth dholth at gmail.com writes:
For one thing you can have more than one mysql = in the same
sqlalchemy.dialects. I think in this instance the string parsing is
Don't you say in the PEP about the key that It
On Thu, Jul 18, 2013 at 4:36 PM, Paul Moore p.f.mo...@gmail.com wrote:
As regards console scripts, I think they should be rewritten to remove the
dependency on pkg_resources. That should be a setuptools fix,
As others have already mentioned, this is not a bug but a feature.
Setuptools-generated
On Thu, Jul 18, 2013 at 7:09 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
PJ Eby pje at telecommunity.com writes:
While other strategies are definitely possible, distlib's approach is
not backward-compatible, as it means installing new versions of a
Correct, because distlib does not support
On Tue, Jul 16, 2013 at 8:23 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 16 July 2013 12:42, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
I thought that 64 bit Windows could run 32 bit Windows .exe files
(although I don't have a way to check this).
Yes, but there are 32-bit and 64-bit
On Thu, Jul 11, 2013 at 10:20 AM, Brett Cannon br...@python.org wrote:
And if people want to promote the -m option then the executable scripts just
become a secondary convenience. Plus you can't exactly require setuptools to
create those scripts at install-time with Python if that's when they
On Wed, Jul 3, 2013 at 10:51 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
If you deserialize the JSON at an URL like the above into a dict, the PEP
426 metadata is available in the subdict at key index-metadata in the
top-level dict. Example from setuptools 0.7.5:
index-metadata: {
On Wed, Jul 3, 2013 at 2:34 PM, Donald Stufft don...@stufft.io wrote:
PEP426 does not support dependency_links.
Right - I would've expected direct references in this scenario,
assuming the PEP still has them.
___
Distutils-SIG maillist -
On Tue, Jul 2, 2013 at 6:59 AM, Iwan Vosloo i...@reahl.org wrote:
Hi there,
We have been struggling to find a nice way to list all the modules (or
packages) that are part of a particular Distribution (or egg). Nice should
also mean that it works when the egg is installed. We have a need to do
On Tue, Jul 2, 2013 at 1:30 PM, Iwan Vosloo i...@reahl.org wrote:
On 02/07/2013 17:08, PJ Eby wrote:
If you are targeting at least Python 2.5, see:
http://docs.python.org/2/library/pkgutil.html#pkgutil.walk_packages
We're targeting Python 2.7.
Trouble is that pkgutil.walk_packages needs
On Wed, Jun 26, 2013 at 1:40 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
(a) Repeatability (not possible with a generic latest version URL).
ISTM that forcing repeatability in the spec implies the inability to
do development with requirements that are also in development, unless
there is
On Wed, Jun 19, 2013 at 4:50 PM, Jason R. Coombs jar...@jaraco.com wrote:
What’s the next step to support this bootstrap script?
Can you just upload it with the docs?
___
Distutils-SIG maillist - Distutils-SIG@python.org
On Wed, Jun 5, 2013 at 2:47 PM, Donald Stufft don...@stufft.io wrote:
One of the big problems with download_url is that the data in setup.py is
used in (and influences the content of) the final dist file. This means that
inside of a setup.py you won't know what the hash of the final file is. So
On Sat, Jun 1, 2013 at 4:29 PM, Lennart Regebro rege...@gmail.com wrote:
On Sat, Jun 1, 2013 at 9:20 PM, Paul Moore p.f.mo...@gmail.com wrote:
I'm -1 on anything that doesn't involve at least a minimal level of human
involvement (possibly excepting an initial clean up exercise for projects
On Sat, May 25, 2013 at 4:06 AM, Matt Wilkie map...@gmail.com wrote:
... or use a script that doesn't depend on entry points
not desirable, as we like the .exe entry points creates and don't want
to use a batch file (the are you sure you want to quit? message on
ctrl-c is annoying)
, or copy
On Sat, May 25, 2013 at 4:40 PM, Jason R. Coombs jar...@jaraco.com wrote:
https://bitbucket.org/pypa/setuptools/downloads
You may be already aware of this, but the installation instructions
don't match the available downloads. I was previously thinking we
should just drop binary distributions
On Sat, May 25, 2013 at 7:02 PM, Jason R. Coombs jar...@jaraco.com wrote:
I heard in person by a newer
Windows user recently, that they still hear that Setuptools is still
considered friendlier than Distribute.
Without knowing what exactly they considered friendlier, I'm not sure
what to
On Wed, May 22, 2013 at 8:12 PM, Matt Wilkie map...@gmail.com wrote:
How do I get my installer to include Distribute so I don't have to tell our
users before you install our program you have to go install this other
program?
Setuptools (which Distribute is based on) is designed for shipping
On Sun, May 19, 2013 at 7:26 PM, Richard Jones rich...@python.org wrote:
Donald wrote a handy script to help make this easier:
https://pypi.python.org/pypi/pypi-show-urls
Doesn't seem to work for me:
$ pypi-show-urls -u pje
Traceback (most recent call last):
File /usr/bin/pypi-show-urls,
On Mon, May 20, 2013 at 1:03 PM, Lennart Regebro rege...@gmail.com wrote:
On Mon, May 20, 2013 at 6:05 PM, PJ Eby p...@telecommunity.com wrote:
On Sun, May 19, 2013 at 7:26 PM, Richard Jones rich...@python.org wrote:
Donald wrote a handy script to help make this easier:
https
1 - 100 of 256 matches
Mail list logo
