[Distutils] Fwd: Error getting pyodbc from pypi shared some log
Please look at https://pypi.python.org/pypi/pyodbc the download url of the
said package got missing.
-- Forwarded message --
From: Nilakhya Chatterjee nilakhya.chatter...@globallogic.com
Date: Wed, Feb 26, 2014 at 6:46 PM
Subject: Error getting pyodbc from pypi shared some log
To: mich...@kleehammer.com
No distributions at all found for pyodbc=3.0.7 (from
vertica-sqlalchemy-0.2)
Exception information:
Traceback (most recent call last):
File
/home/ubuntu/myenv/local/lib/python2.7/site-packages/pip/basecommand.py,
line 122, in main
status = self.run(options, args)
File
/home/ubuntu/myenv/local/lib/python2.7/site-packages/pip/commands/install.py,
line 270, in run
requirement_set.prepare_files(finder, force_root_egg_info=self.bundle,
bundle=self.bundle)
File /home/ubuntu/myenv/local/lib/python2.7/site-packages/pip/req.py,
line 1157, in prepare_files
url = finder.find_requirement(req_to_install, upgrade=self.upgrade)
File /home/ubuntu/myenv/local/lib/python2.7/site-packages/pip/index.py,
line 285, in find_requirement
raise DistributionNotFound('No distributions at all found for %s' % req)
DistributionNotFound: No distributions at all found for pyodbc=3.0.7 (from
vertica-sqlalchemy-0.2)
Let me know if you can quickly resolve this.
Tx !
--
Nilakhya | Consultant Engineering
GlobalLogic
P +x.xxx.xxx. M +91.989.112.5770 S skype
www.globallogic.com
http://www.globallogic.com/
http://www.globallogic.com/email_disclaimer.txt
--
Nilakhya | Consultant Engineering
GlobalLogic
P +x.xxx.xxx. M +91.989.112.5770 S skype
www.globallogic.com
http://www.globallogic.com/
http://www.globallogic.com/email_disclaimer.txt
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Is there any sense to put setuptools as a requirement?
Hi! I've seen people putting 'setuptools' in 'install_requires' in setup.py starting with import from setuptools like this: from setuptools import setup, find_packages Does it make any sense? In what circumstances should 'setuptools' be listed in 'install_requires' or 'setup_requires'? Regards, Piotr Dobrogost ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Is there any sense to put setuptools as a requirement?
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: from setuptools import setup, find_packages Does it make any sense? In what circumstances should 'setuptools' be listed in 'install_requires' or 'setup_requires'? Someone can correct me if I'm wrong, but you can list setuptools in setup.cfg as part of setup_requires and then tools that read setup.cfg instead of/prior to executing setup.py can know they need setuptools to properly execute setup.py. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Is there any sense to put setuptools as a requirement?
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: from setuptools import setup, find_packages Does it make any sense? In what circumstances should 'setuptools' be listed in 'install_requires' or 'setup_requires'? It makes sense when you use setuptools to implement namespace packages. So, for example in zope packages, the __init__.py in the zope namespace package typically has: import pkg_resources pkg_resources.declare_namespace(__name__) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Is there any sense to put setuptools as a requirement?
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: from setuptools import setup, find_packages Does it make any sense? In what circumstances should 'setuptools' be listed in 'install_requires' or 'setup_requires'? It makes sense when you use setuptools to implement namespace packages. So, for example in zope packages, the __init__.py in the zope namespace package typically has: import pkg_resources pkg_resources.declare_namespace(__name__) It also makes sense if you use entry points, the plugin finder, or any other pkg_resources features, for that matter. ;-) Or if you reuse setuptools functionality (e.g. easy_install) to install plugins for your app. But in general, it only makes sense to depend on setuptools if your actual project contents (aside from setup.py) are importing things from pkg_resources or setuptools. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Is there any sense to put setuptools as a requirement?
with pip 1.5 able to install from wheel without setuptools, it's more critical now to declare the dependency (in the cases PJ mentions), to ensure setuptools gets installed. On Sat, Mar 1, 2014 at 6:49 PM, PJ Eby p...@telecommunity.com wrote: 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: from setuptools import setup, find_packages Does it make any sense? In what circumstances should 'setuptools' be listed in 'install_requires' or 'setup_requires'? It makes sense when you use setuptools to implement namespace packages. So, for example in zope packages, the __init__.py in the zope namespace package typically has: import pkg_resources pkg_resources.declare_namespace(__name__) It also makes sense if you use entry points, the plugin finder, or any other pkg_resources features, for that matter. ;-) Or if you reuse setuptools functionality (e.g. easy_install) to install plugins for your app. But in general, it only makes sense to depend on setuptools if your actual project contents (aside from setup.py) are importing things from pkg_resources or setuptools. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Remaining tasks before metadata 2.0 can be accepted (was Re: The PEP 426 defined metadata version will be metadata 3.0)
On 27 February 2014 10:46, Marcus Smith qwc...@gmail.com wrote: that would be good. If you did, I would link to the tasks from the PUG future page. OK, these are the things I consider blockers for an accepted metadata 2.0 spec: https://bitbucket.org/pypa/pypi-metadata-formats/issues?priority=blockerstatus=openstatus=new Finalising PEP 426/440/459 is on me. At this point, I think that consists of *taking away* things that aren't yet settled (specifically metadata hooks), so we can see how far this next iteration actually gets us before trying to solve the remaining problems that need some kind of trigger support. A required preliminary task is to create a revision of PEP 425 that expands its scope to also handle the parts of the file/directory naming scheme that are common across sdist, wheel and the installation database (with compatibility tags becoming a subsection), as well as fixing the definition of the compatibility tags to better handle Windows and Python 2.x binary extensions. (There's a separate non-blocker issue for better Linux/POSIX support - building from source is far more common there, and both conda and Linux distro packages remain available as a near-term workaround for the lack of upstream binary packages) The other blockers are then sdist 2.0, wheel 1.1 and a second revision of the installation database format. There are more issues in that repo, but they're ones that I don't consider *essential* as part of a usable metadata 2.0 spec - they're about things like Linux binary support, distributing full applications in addition to libraries and handling things that may require the ability to run code at installation time. Once metadata 2.0 itself is published, we can likely explore several of them as extensions before committing to anything in the core PEPs. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Remaining tasks before metadata 2.0 can be accepted (was Re: The PEP 426 defined metadata version will be metadata 3.0)
On 2 March 2014 15:22, Nick Coghlan ncogh...@gmail.com wrote: On 27 February 2014 10:46, Marcus Smith qwc...@gmail.com wrote: that would be good. If you did, I would link to the tasks from the PUG future page. OK, these are the things I consider blockers for an accepted metadata 2.0 spec: https://bitbucket.org/pypa/pypi-metadata-formats/issues?priority=blockerstatus=openstatus=new Finalising PEP 426/440/459 is on me. At this point, I think that consists of *taking away* things that aren't yet settled (specifically metadata hooks), so we can see how far this next iteration actually gets us before trying to solve the remaining problems that need some kind of trigger support. A required preliminary task is to create a revision of PEP 425 that expands its scope to also handle the parts of the file/directory naming scheme that are common across sdist, wheel and the installation database (with compatibility tags becoming a subsection), as well as fixing the definition of the compatibility tags to better handle Windows and Python 2.x binary extensions. (There's a separate non-blocker issue for better Linux/POSIX support - building from source is far more common there, and both conda and Linux distro packages remain available as a near-term workaround for the lack of upstream binary packages) The other blockers are then sdist 2.0, wheel 1.1 and a second revision of the installation database format. Just remembered two more blockers - updating the JSON schema files to account for the switch to making heavy use of schema extensions and rerunning the PyPI compatibility analysis. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Deferring metadata hooks
I've just posted updated versions of PEP 426 and 459 that defer the metadata hooks feature. The design and behaviour of that extension is still way too speculative for me to approve in its current form, but I also don't want to hold up the rest of the changes in metadata 2.0 while we thrash out the details of a hook system. That said, I still don't want us to get into a situation where someone later publishes a wheel file that expects metadata hook support and older tools silently install it without running the hooks. Accordingly, the revised PEP 426 adds a single simpler feature to the extensions system: the idea of a required extension. If a project sets that flag for an extension (by including required_extension: true in the extension metadata), and an installation tool doesn't understand it, then the tool is required to either fail the installation attempt entirely or else fall back to installing from source. That way, project authors will be able to distinguish between these metadata hooks are just an optimisation, things will still work if you don't run them and if you don't run these hooks, your installation will be broken. I think this approach may also encourage a design where projects do something sensible *by default* (e.g. NumPy defaulting to SSE2) and then use the (not yet defined) post-installation hooks to potentially *change away* from the default to something more optimised for that particular system (e.g. NumPy overwriting itself with an SSE3 version), while still *allowing* developers to refuse to let the software install if the metadata hooks won't be run. Regards, Nick. P.S. The draft PEP for metadata hooks is still available at https://bitbucket.org/pypa/pypi-metadata-formats/src/default/metadata-hooks.rst -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
