A low-level library which implements some Python packaging standards (PEPs) and which could be used by third-party packaging tools to achieve interoperability.
Home Page: http://distlib.readthedocs.io/
License: Other
Original report by Anonymous.
This is primarily to support pytz (https://pypi.python.org/simple/pytz/)
The format is kind of stupid [date][a-z] but it throws an UnsupportedVersionError currently.
#!python
>>> from distlib.locators import DirectoryLocator
>>> from distlib import version
>>> l = DirectoryLocator('/opt/pypi/cache/')
>>> l.locate('pytz')
>>> l.get_project('pytz')
{'2013b': <Distribution pytz (2013b) [file:///opt/pypi/cache/pytz/pytz-2013b.zip]>, '2012f': <Distribution pytz (2012f) [file:///opt/pypi/cache/pytz/pytz-2012f.zip]>}
>>> v = version.get_scheme('default')
>>> m = v.matcher('pytz')
>>> m.match('2013b')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/opt/pypi/lib/python2.6/site-packages/distlib/version.py", line 113, in match
version = self.version_class(version)
File "/opt/pypi/lib/python2.6/site-packages/distlib/version.py", line 29, in __init__
self._parts = parts = self.parse(s)
File "/opt/pypi/lib/python2.6/site-packages/distlib/version.py", line 635, in parse
def parse(self, s): return _adaptive_key(s)
File "/opt/pypi/lib/python2.6/site-packages/distlib/version.py", line 630, in _adaptive_key
result = _semantic_key(ss) # let's hope ...
File "/opt/pypi/lib/python2.6/site-packages/distlib/version.py", line 597, in _semantic_key
raise UnsupportedVersionError(s)
distlib.version.UnsupportedVersionError: 2013b
>>> m.version_class
<class 'distlib.version.AdaptiveVersion'>
Original report by Paul Moore (Bitbucket: pmoore, GitHub: pmoore).
The distlib wheel install function does not correct the #! line on installed scripts to point to the correct Python executable.
Note: It is possible to use Wheel.install to install into a Python environment other than the one running the command - this needs to be possible. I am using this to install wheels into a newly-created virtualenv (which may not itself have distlib installed)
Original report by Paul Moore (Bitbucket: pmoore, GitHub: pmoore).
The original report had attachments: distil.log
See the attached log.
Original report by Kevin Horn (Bitbucket: khorn, GitHub: khorn).
I get a traceback when calling EggInfoDistribution.list_installed_files
#!
Traceback (most recent call last):
File "pynstall.py", line 58, in <module>
ShowInstalledApp.run()
File "C:\Users\funsize\Envs\pynstall\Lib\site-packages\plumbum\cli.py", line 563, in run
retcode = inst.main(*tailargs)
File "pynstall.py", line 41, in main
for ifile in dist.list_installed_files():
File "c:\users\funsize\envs\pynstall\src\distlib\distlib\database.py", line 790, in list_installed_files
result.append((item, _md5(item), _size(item)))
File "c:\users\funsize\envs\pynstall\src\distlib\distlib\database.py", line 773, in _md5
return md5(content).hexdigest()
NameError: global name 'md5' is not defined
looks like maybe it should have been _md5 instead.
Original report by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver).
The Resource class has 4 attributes (as_stream, file_path, bytes, size) that only make sense if it's not a container, and 1 (resources) that only makes sense if it is. That only leaves finder, name and is_container that make sense in both situations.
It seems like this would make more sense as two classes: Resource/ResourceContainer, or DataResource/ContainerResource, or something like that.
Sorry if this has already been discussed elsewhere - I didn't pick up any rationale for this from the design docs.
Original report by Donald Stufft (Bitbucket: dstufft, GitHub: dstufft).
Most software doesn't need nor care about being able to select what version of python you're executing it with. Having ScriptMaker default to creating a foo-X.Y seems like needlessly adding extra files that someone didn't ask for, with very little, if any benefit.
Perhaps ScriptMaker should just default to only having the versionless variant?
Original report by Anonymous.
The PyPI entry for distlib links to http://pythonhosted.org//distlib which has links to the old repo and now closed issue tracker: http://pythonhosted.org/distlib/overview.html#project-status
Original report by me.
You can add e.g. /path/to/file.zip/lib to sys.path to import from the lib folder in the zip. This scenario needs to be tested.
Thanks to Daniel Holth for the suggestion.
Original report by Anonymous.
If the user is created without a home directory and then we try to create a virtualenv for that user, we see a failure because we can't create the '.distlib' directory in the user's home directory.
Example output:
#!python
Installing setuptools, pip...
Complete output from command /edx/app/supervisor/...upervisor/bin/python -c "import sys, pip; pip...ll\"] + sys.argv[1:])" setuptools pip:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/local/lib/python2.7/dist-packages/virtualenv_support/pip-1.5-py2.py3-none-any.whl/pip/__init__.py", line 11, in <module>
File "/usr/local/lib/python2.7/dist-packages/virtualenv_support/pip-1.5-py2.py3-none-any.whl/pip/vcs/subversion.py", line 4, in <module>
File "/usr/local/lib/python2.7/dist-packages/virtualenv_support/pip-1.5-py2.py3-none-any.whl/pip/index.py", line 16, in <module>
File "/usr/local/lib/python2.7/dist-packages/virtualenv_support/pip-1.5-py2.py3-none-any.whl/pip/wheel.py", line 23, in <module>
File "/usr/local/lib/python2.7/dist-packages/virtualenv_support/pip-1.5-py2.py3-none-any.whl/pip/_vendor/distlib/scripts.py", line 15, in <module>
File "/usr/local/lib/python2.7/dist-packages/virtualenv_support/pip-1.5-py2.py3-none-any.whl/pip/_vendor/distlib/resources.py", line 105, in <module>
File "/usr/local/lib/python2.7/dist-packages/virtualenv_support/pip-1.5-py2.py3-none-any.whl/pip/_vendor/distlib/resources.py", line 40, in __init__
File "/usr/local/lib/python2.7/dist-packages/virtualenv_support/pip-1.5-py2.py3-none-any.whl/pip/_vendor/distlib/util.py", line 602, in get_cache_base
File "/edx/app/supervisor/venvs/supervisor/lib/python2.7/os.py", line 150, in makedirs
makedirs(head, mode)
File "/edx/app/supervisor/venvs/supervisor/lib/python2.7/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 13] Permission denied: '/home/supervisor'
----------------------------------------
...Installing setuptools, pip...done.
:stderr: Traceback (most recent call last):
File "/usr/local/bin/virtualenv", line 9, in <module>
load_entry_point('virtualenv==1.11', 'console_scripts', 'virtualenv')()
File "/usr/local/lib/python2.7/dist-packages/virtualenv.py", line 820, in main
symlink=options.symlink)
File "/usr/local/lib/python2.7/dist-packages/virtualenv.py", line 988, in create_environment
install_wheel(to_install, py_executable, search_dirs)
File "/usr/local/lib/python2.7/dist-packages/virtualenv.py", line 956, in install_wheel
'PIP_NO_INDEX': '1'
File "/usr/local/lib/python2.7/dist-packages/virtualenv.py", line 898, in call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command /edx/app/supervisor/...upervisor/bin/python -c "import sys, pip; pip...ll\"] + sys.argv[1:])" setuptools pip failed with error code 1
Original report by Paul Moore (Bitbucket: pmoore, GitHub: pmoore).
There appears to be an issue with creating a distlib wheel via pip wheel. It also manifests itself when vendoring distlib into pip (which uses pip install -t).
The issue is that pip install -t . distlib doesn't seem to copy the script wrapper executables.
This may be because of some unfortunate interaction between MANIFEST.in (where these files are listed) and pip/setuptools. So this may not be a distlib issue per se. But it does mean that at present the ScriptMaker class in the vendored distlib included with pip is non-functional.
Original report by Alex Grönholm (Bitbucket: [Alex Grönholm](https://bitbucket.org/Alex Grönholm), ).
Steps to reproduce:
Original report by Paul Moore (Bitbucket: pmoore, GitHub: pmoore).
Now that distlib includes wheel support, it would be useful to allow locators to find wheels. At the moment, there are very few wheels on PyPI, but I am using distlib to write a script to maintain a local cache of sdists and generate wheels from them. For that, being able to use the locator interface to check if my local wheel cache already includes a wheel for a given distribution/version would be perfect.
(By the way, the distribution name_and_version property is in precisely the format to use as a requirement to locate that distribution/version in a separate locator. Is this intentional, and is it guaranteed to remain true? I hope so, as it's just what I need for maintaining a local cache, and maybe if it is, the documentation could mention this usage).
Original report by Anonymous.
See http://bugs.python.org/issue19688. For Python 3.4, unescape() is now documented and moved.
Original report by Donald Stufft (Bitbucket: dstufft, GitHub: dstufft).
Is there any reason not to simplify the generated script? Something like.
# -*- coding: utf-8 -*-
if __name__ == '__main__':
import sys
from %(module)s import %(func)s
sys.exit(%(func)s())
I believe would do the exact same thing as you're doing now, with less code.
Original report by James Tocknell (Bitbucket: aragilar, GitHub: aragilar).
Currently the distlib.wheel.Wheel only allows for creating a wheel from files or install files from a wheel, not modifying the wheel in place or creating a new wheel wheel from an old one. Use cases for this would be to update the metadata in the wheel from a legacy version to 2.0, or to add dependencies not contained in setup.py (e.g. add numpy dependency to a scipy wheel, which was what I'm trying to do).
A workaround is to install the wheel into some temporary directory, do the required modifications, and then rebuild, or to modify the zip file directly (what I'm doing currently), but this is more likely to create buggy wheels.
Original report by Marcus Smith (Bitbucket: qwcode, GitHub: qwcode).
If the "legacy" version support is meant to replicate pkg_resources, then it shouldn't be working off a discrete list for prereleases ( 'a', 'alpha', 'b', 'beta', 'c', 'rc', 'r', '@', and 'pre' )
it's whatever sorts before "final".
from pkg_resources.py:parse_version
#!python
Strings like "a", "b", "c", "alpha", "beta", "candidate" and so on (that
come before "final" alphabetically) are assumed to be pre-release versions,
so that the version "2.4" is considered newer than "2.4a1".
Finally, to handle miscellaneous cases, the strings "pre", "preview", and
"rc" are treated as if they were "c", i.e. as though they were release
candidates, and therefore are not as new as a version string that does not
contain them, and "dev" is replaced with an '@' so that it sorts lower than
than any other pre-release tag.
Original report by Donald Stufft (Bitbucket: dstufft, GitHub: dstufft).
It would be useful for distlib to function when optional modules are not compiled into CPython. Notably the SSL module.
Ideally the only optional module that would be required is the zlib module, because without compression none of the packaging formats can be worked with.
Original report by C Anthony Risinger (Bitbucket: anthonyrisinger, GitHub: anthonyrisinger).
this is more of a question... direct me elsewhere if more appropriate.
ENVIRON
setuptools (0.9.5)
wheel (0.18.0)
distlib (HEAD)
my setup generates wheels for everything (including setuptools/wheel/distlib), and installs with wheel module (this will be moved to distlib as time allows), thus i have 100% non-legacy environment.
the problem is the pkg_resources in current setuptools completely chokes when distributions are installed to a non-root zipfile, eg. path/to/python.zip/lib/python2.7/site-packages/*.dist-info. granted this is a setuptools problem i need to report (and furthermore, unzipped eggs within such a zipfile will cause exponential scanning of itself for each egg added, and never completes)... is there a nice way to handle this in distlib alone? already? other thoughts?
i saw the pkg_resources.py impl submitted to pip (pypa/pip#909):
...and tried that out (after fix _legacy_key), but it is missing load_entry_point :(
ATM, load_entry_point is the only thing i need and it seems easy-ish to implement, but i thought i'd drop a note here to learn more about the problem itself, or any other relevant infos... thoughts?
Original report by Daniel Holth (Bitbucket: [Daniel Holth](https://bitbucket.org/Daniel Holth), ).
At least on Python 2.7, distlib's setup.py does not work.
$ setup.py install
error: package directory 'distlib/compat' does not exist
Original report by Paul Moore (Bitbucket: pmoore, GitHub: pmoore).
The original report had attachments: pip.zip
If I zip up a copy of pip (with its internal vendored copy of distlib 0.1.6) and an appropriate __main__.py, then when I try to install a wheel from PyPI I get the following error:
>virtualenv --no-setuptools xx
Using real prefix 'C:\\Apps\\Python33'
New python executable in xx\Scripts\python.EXE
(ve) PS 13:08 C:\Work\personal
>xx\scripts\python .\pip\pip.zip list
(ve) PS 13:08 C:\Work\personal
>xx\scripts\python .\pip\pip.zip install setuptools
Downloading/unpacking setuptools
Installing collected packages: setuptools
Cleaning up...
Exception:
Traceback (most recent call last):
File ".\pip\pip.zip\pip\basecommand.py", line 122, in main
status = self.run(options, args)
File ".\pip\pip.zip\pip\commands\install.py", line 275, in run
requirement_set.install(install_options, global_options, root=options.root_path)
File ".\pip\pip.zip\pip\req.py", line 1373, in install
requirement.install(install_options, global_options, *args, **kwargs)
File ".\pip\pip.zip\pip\req.py", line 655, in install
self.move_wheel_files(self.source_dir, root=root)
File ".\pip\pip.zip\pip\req.py", line 886, in move_wheel_files
pycompile=self.pycompile,
File ".\pip\pip.zip\pip\wheel.py", line 324, in move_wheel_files
generated.extend(maker.make(spec))
File ".\pip\pip.zip\pip\_vendor\distlib\scripts.py", line 304, in make
self._make_script(entry, filenames, options=options)
File ".\pip\pip.zip\pip\_vendor\distlib\scripts.py", line 208, in _make_script
self._write_script(scriptnames, shebang, script, filenames, ext)
File ".\pip\pip.zip\pip\_vendor\distlib\scripts.py", line 150, in _write_script
launcher = self._get_launcher('t')
File ".\pip\pip.zip\pip\_vendor\distlib\scripts.py", line 283, in _get_launcher
result = finder(distlib_package).find(name).bytes
AttributeError: 'NoneType' object has no attribute 'bytes'
Storing debug log for failure in C:\Users\uk03306\pip\pip.log
It looks to me like the code in distlib to locate the launcher stubs is failing when distlib is bundled in a zip file like this. It's not a critical issue, but it would be nice if this worked (and it may indicate a corner case in distlib that's not being handled properly).
Original report by C Anthony Risinger (Bitbucket: anthonyrisinger, GitHub: anthonyrisinger).
distil-258fbf-32a4bc.py, but i think the issue itself is with distlib:
...only the oldest (0.1.7) works as expected, the others simply produce this "error message":
#!shell-session
[any@sh ~]$ python2 ./distil-258fbf-32a4bc.py package --formats=wheel
'index-metadata'
...same problem here:
...it's worth noting that the default_locator does not return any of these missing dists either (if that's obvious/given, forgive me)
also, i was unable to create wheels for these due to some undefined symbol issues (could not look further):
Original report by Anonymous.
[...]
File "distlib/locators.py", line 1187, in find
self.try_to_replace(p, other, problems)
File "distlib/locators.py", line 1076, in try_to_replace
problems.add(('cantreplace', provider, other, unmatched))
TypeError: unhashable type: 'set'...can't put a set in a set, maybe frozenset(...) it first
Original report by Mike Verdone (Bitbucket: sixohsix, GitHub: sixohsix).
I was using caniusepython3 and managed to trigger an AttributeError in distlib by feeding it a package name that isn't on PyPI. I'm sorry I can't provide much more info, but the traceback is below.
[ERROR] Failed to get external data for %s: %s
Traceback (most recent call last):
File "/Users/miv/.venvs3.4/caniusepython3_master/lib/python3.4/site-packages/distlib/util.py", line 745, in _get_external_data
resp = urlopen(url)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/urllib/request.py", line 153, in urlopen
return opener.open(url, data, timeout)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/urllib/request.py", line 461, in open
response = meth(req, response)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/urllib/request.py", line 574, in http_response
'http', request, response, code, msg, hdrs)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/urllib/request.py", line 499, in error
return self._call_chain(*args)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/urllib/request.py", line 433, in _call_chain
result = func(*args)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/urllib/request.py", line 582, in http_error_default
raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 404: Not Found
[WARNING] xxx.sncodecs not found
Traceback (most recent call last):
File "/Users/miv/.venvs3.4/caniusepython3_master/bin/caniusepython3", line 9, in <module>
load_entry_point('caniusepython3==1.2.1', 'console_scripts', 'caniusepython3')()
File "/Users/miv/projects/caniusepython3/caniusepython3/__main__.py", line 152, in main
check(projects_from_cli(args))
File "/Users/miv/projects/caniusepython3/caniusepython3/__main__.py", line 140, in check
blockers = ciu.blocking_dependencies(projects, ciu.all_py3_projects())
File "/Users/miv/projects/caniusepython3/caniusepython3/__init__.py", line 182, in blocking_dependencies
for parent, deps in zip(check, executor.map(dependencies, check)):
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/concurrent/futures/_base.py", line 549, in result_iterator
yield future.result()
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/concurrent/futures/_base.py", line 395, in result
return self.__get_result()
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/concurrent/futures/_base.py", line 354, in __get_result
raise self._exception
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/concurrent/futures/thread.py", line 54, in run
result = self.fn(*self.args, **self.kwargs)
File "/Users/miv/projects/caniusepython3/caniusepython3/__init__.py", line 154, in dependencies
located = distlib.locators.locate(project_name, prereleases=True)
File "/Users/miv/.venvs3.4/caniusepython3_master/lib/python3.4/site-packages/distlib/locators.py", line 331, in locate
versions = self.get_project(r.name)
File "/Users/miv/.venvs3.4/caniusepython3_master/lib/python3.4/site-packages/distlib/locators.py", line 158, in get_project
result = self._get_project(name)
File "/Users/miv/.venvs3.4/caniusepython3_master/lib/python3.4/site-packages/distlib/locators.py", line 900, in _get_project
d = locator.get_project(name)
File "/Users/miv/.venvs3.4/caniusepython3_master/lib/python3.4/site-packages/distlib/locators.py", line 158, in get_project
result = self._get_project(name)
File "/Users/miv/.venvs3.4/caniusepython3_master/lib/python3.4/site-packages/distlib/locators.py", line 577, in _get_project
del self.result
AttributeError: result
Original report by C Anthony Risinger (Bitbucket: anthonyrisinger, GitHub: anthonyrisinger).
The original report had attachments: 0001-resources-back-all.patch
i have the entire stdlib/site-packages in one zipfile, where the zipfile also has a prefix of lib/python2.7 (eg. python27.zip/lib/python2.7/os.py not python27.zip/os.py)
the site-packages "directory" -- within the zip -- contains numerous dist[-info]s,,, each installed from wheels conforming to latest metadata practices
...in such setup, distlib.database.DistributionPath().get_distributions() is forever empty!
rely on the __loader__ and use resources!
#!python
#..charge the cache (as/if needed)
pkgutil.get_importer(path)
loader = sys.path_importer_cache.get(path)
finder = distlib.resources._finder_registry.get(type(loader))
Original report by Domen Kožar (Bitbucket: iElectric, ).
https://distlib.readthedocs.org/en/latest/ only includes 0.1.1dev documentation but not 0.1.0
Original report by Paul Moore (Bitbucket: pmoore, GitHub: pmoore).
def get_resource_path(self, relative_path):
resources_file = self.get_distinfo_file('RESOURCES')
try:
resources_reader = csv.reader(resources_file, delimiter=',',
lineterminator='\n')
get_distinfo_file opens in text mode by default. But csv.reader must always be passed a binary mode file (see the CSV module documentation).
The fix should not be too hard, but may need some tweaking to handle both Python 2.x and 3.x, because opening a file in binary mode differs between the two.
Original report by Anonymous.
https://distlib.readthedocs.org/en/latest/tutorial.html#getting-hold-of-root-certificates
The "note" there is no longer accurate
Original report by Martin Dengler (Bitbucket: [Martin Dengler](https://bitbucket.org/Martin Dengler), ).
This issue has three parts:
__VENV_LAUNCHER__ override sys.executable, regardless of sys.platform?__VENV_LAUNCHER__? It doesn't seem to be documented anywhere google-able.I stumbled across __VENV_LAUNCHER__ in distlib.util.get_executable(), which uses that variable iff sys.platform == 'darwin', whereas setuptools seems to respect that variable regardless of sys.platform (see for example https://bitbucket.org/pypa/setuptools/src/646b366da678257501b00a7328c4e73b8fb667db/setuptools/command/easy_install.py?at=default#cl-56 ).
I am happy to provide patches if it would help. I am happy to separately record any of the three parts to this issue if that's more appropriate.
Original report by Richard Jones (Bitbucket: r1chardj0n3s, GitHub: r1chardj0n3s).
This package is not Python 2.6 compatible but I believe that is the intention.
The issue is in the distlib._backport.sysconfig module's inability to find sysconfig.cfg:
#!bash
(py26) richard$ python -V
Python 2.6.7
(py26) richard$ pip install distlib
Downloading/unpacking distlib
...
(py26) richard$ python -c 'import distlib.wheel'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Users/richard/virtualenvs/py26/lib/python2.6/site-packages/distlib/wheel.py", line 47, in <module>
VER_SUFFIX = sysconfig.get_config_var('py_version_nodot')
File "/Users/richard/virtualenvs/py26/lib/python2.6/site-packages/distlib/_backport/sysconfig.py", line 599, in get_config_var
return get_config_vars().get(name)
File "/Users/richard/virtualenvs/py26/lib/python2.6/site-packages/distlib/_backport/sysconfig.py", line 495, in get_config_vars
_init_posix(_CONFIG_VARS)
File "/Users/richard/virtualenvs/py26/lib/python2.6/site-packages/distlib/_backport/sysconfig.py", line 346, in _init_posix
makefile = get_makefile_filename()
File "/Users/richard/virtualenvs/py26/lib/python2.6/site-packages/distlib/_backport/sysconfig.py", line 340, in get_makefile_filename
return os.path.join(get_path('stdlib'), config_dir_name, 'Makefile')
File "/Users/richard/virtualenvs/py26/lib/python2.6/site-packages/distlib/_backport/sysconfig.py", line 459, in get_path
return get_paths(scheme, vars, expand)[name]
File "/Users/richard/virtualenvs/py26/lib/python2.6/site-packages/distlib/_backport/sysconfig.py", line 447, in get_paths
_ensure_cfg_read()
File "/Users/richard/virtualenvs/py26/lib/python2.6/site-packages/distlib/_backport/sysconfig.py", line 74, in _ensure_cfg_read
assert _cfgfile, 'sysconfig.cfg exists'
AssertionError: sysconfig.cfg exists
Original report by Brett Cannon (Bitbucket: brettcannon, GitHub: brettcannon).
E.g. [ERROR] Failed to get external data for %s: %s
Original report by Paul Moore (Bitbucket: pmoore, GitHub: pmoore).
Wheels that use metadata 1.x (e.g., all wheels created by bdist_wheel or pip wheel) specify console scripts in the setuptools metadata file entry-points.txt. Distlib doesn't appear to parse this file, and so fails to create script wrappers for such wheels.
Original report by Tshepang Lekhonkhobe (Bitbucket: tshepang, GitHub: tshepang).
Here goes:
$ make --directory docs/ html
make: Entering directory `/home/tshepang/projects/distlib/docs'
sphinx-build -b html -d _build/doctrees . _build/html
Running Sphinx v1.2b1
loading pickled environment... failed: [Errno 2] No such file or directory: '/home/tshepang/projects/distlib/docs/_build/doctrees/environment.pickle'
Theme error:
no theme named 'pydoctheme' found (missing theme.conf?)
make: *** [html] Error 1
make: Leaving directory `/home/tshepang/projects/distlib/docs'
Original report by C Anthony Risinger (Bitbucket: anthonyrisinger, GitHub: anthonyrisinger).
the regex:
(\s*#!("[^"]+"|[\w/\\:.]+))\s+(.*)$
...does not reflect all valid shebangs, eg. an @ in the path leads to failure. also, even though .match(...) is used, the regex should be anchored:
^(\s*#!("[^"]+"|[\w/\\:.]+))\s+(.*)$
...anything save \0 and / may be in the path:
^(\s*#!("[^"]+"|\S+))\s+(.*)$
...there are better ways too (such as setuptools method of open() + readline()) but this makes stuff go again.
Original report by Tshepang Lekhonkhobe (Bitbucket: tshepang, GitHub: tshepang).
Here goes:
$ make -C docs/ html
make: Entering directory `/home/tshepang/projects/distlib/docs'
sphinx-build -b html -d _build/doctrees . _build/html
Running Sphinx v1.2b1
loading pickled environment... done
building [html]: targets for 3 source files that are out of date
updating environment: 0 added, 4 changed, 0 removed
reading sources... [100%] tutorial
/home/tshepang/projects/distlib/docs/depgraph.rst:None: WARNING: image file not readable: depgraph-output.png
/home/tshepang/projects/distlib/docs/internals.rst:4: WARNING: Duplicate explicit target name: "this section".
/home/tshepang/projects/distlib/docs/tutorial.rst:4: WARNING: Duplicate explicit target name: "pep 426".
looking for now-outdated files... none found
pickling environment... done
checking consistency... /home/tshepang/projects/distlib/docs/database.rst:: WARNING: document isn't included in any toctree
/home/tshepang/projects/distlib/docs/depgraph.rst:: WARNING: document isn't included in any toctree
/home/tshepang/projects/distlib/docs/dist.rst:: WARNING: document isn't included in any toctree
/home/tshepang/projects/distlib/docs/metadata.rst:: WARNING: document isn't included in any toctree
/home/tshepang/projects/distlib/docs/util.rst:: WARNING: document isn't included in any toctree
/home/tshepang/projects/distlib/docs/version.rst:: WARNING: document isn't included in any toctree
done
preparing documents... done
writing output... [100%] tutorial
writing additional files... (12 module code pages) _modules/index
genindex py-modindex search
copying static files... WARNING: html_static_path entry '/home/tshepang/projects/distlib/docs/_static' does not exist
done
dumping search index... done
dumping object inventory... done
build succeeded, 10 warnings.
Build finished. The HTML pages are in _build/html.
make: Leaving directory `/home/tshepang/projects/distlib/docs'
Original report by Paul Moore (Bitbucket: pmoore, GitHub: pmoore).
At the moment, distil can install wheels by specifying the full wheel filename (or by downloading wheels from PyPI? I'm not clear if that works yet).
It would be useful to be able to specify a local directory of wheels, and then be able to install requirements from those wheels - for example:
distil -e venv -i /tmp/wheelhouse install lxml
to install the latest lxml from a local wheel.
Original report by Anonymous.
In the point "How you can help" is there a small typo
If you have some time --> abd <-- the inclination
Original report by Paul Moore (Bitbucket: pmoore, GitHub: pmoore).
The PyPI client code looks like it could be very useful (I'm still going through it to understand the details). It would be helpful if there were a documented/guaranteed interface for the crawler(s), so that further classes implementing the interface could be seamlessly added.
For example, a class modeling a local directory of distributions. Or a class modeling a private repository.
Original report by C Anthony Risinger (Bitbucket: anthonyrisinger, GitHub: anthonyrisinger).
given a dep finder like:
#!python
finder = DependencyFinder(AggregatingLocator(
DirectoryLocator('/abs/path/to/sdists', recursive=False),
JSONLocator(),
SimpleScrapingLocator('https://pypi.python.org/simple/', timeout=3.0),
scheme='legacy',
merge=False,
))
...the finder will fail to resolve 'wheel (== 0.18.0)' via JSONLocator if DirectoryLocator returns appropriate -- but incompatible!!! -- results. in my case, 'wheel-0.17.0.tar.gz' was found by DirectoryLocator, and the dict returned from _get_project immediately (since merge=False)... however since this Locator does not fulfill the requirement, an exception is thrown.
i can see from the code/interface that _get_project cannot [currently] determine if a given Locator actually fulfills the requirement until after it returns... unfortunately this makes the AggregatingLocator much less useful (eg. return the first Locator that MEETS THE GIVEN REQUIREMENT, not just matches the key [any requirement])
i propose changing _get_project to a generator that returns the solutuion set from each locator, one at a time, and allow the locate() method to exhaust the sets... note: i did not test this (or look too closely at ramifications -- just an initial guess).
other options may be to implement locate() in AggregatingLocator, add a "greedy" arg (or similar) to Locator.locate... or a new kind of Locator altogether?
Original report by C Anthony Risinger (Bitbucket: anthonyrisinger, GitHub: anthonyrisinger).
results from JSONLocator appear to be unusable sometime within the last 4-6 hrs:
#!python
>>> from distlib.locators import default_locator
>>> # get from JSONLocator only
>>> s = default_locator.locators[0].locate('setuptools')
>>> s.metadata
<Metadata 2.0 setuptools (0.9.1)>
>>> s.metadata.get_requirements()
[...]
File "/home/anthony/devel/local/zppy/external-library/distlib/database.py", li
ne 349, in run_requires
return self._get_requirements('run_requires', 'run_may_require')
File "/home/anthony/devel/local/zppy/external-library/distlib/database.py", li
ne 345, in _get_requirements
env=self.context))
TypeError: unhashable type: 'dict'
my app is actually using the DependencyFinder, and i know for a fact that earlier today it was properly returning set(, , [...])
it could be only some packages are messed up... i changed my tool to cache JSONLocator metadata so i can load it later when it's local (eg. as a way to endow DirectoryLocator with proper metadata)... however, ATM, i don't seem to be able to query anything without an exception, even when using the defaults:
#!python
from distlib.locators import default_locator, DependencyFinder
DependencyFinder(default_locator).find('gitdb')
...throws the same unhashable type :(
Original report by Anonymous.
...please change distil/packager.py:1132
#!python
if operation.get('no-exports', False):
console_scripts = gui_scripts = []
...to...
#!python
if operation.get('no-exports', False):
console_scripts = gui_scripts = dict()
but really, i ask again, can distil simply be given a proper repo? ATM, i automatically decompress and patch distil to behave properly/nicely (forcing it to use a normal copy of BOTH itself AND distlib already on sys.path).. just to get it to print a proper traceback is becoming more annoying than it's worth. im on the fence about using distlib exclusively, since i already use it heavily for other reasons.
i think it offers a great value to what would be my "end user", so i want to include it even if my build process doesn't use it, but without a repo it causes too many interrupts, and the zip stuff is constantly in the way.
Original report by Daniel Holth (Bitbucket: [Daniel Holth](https://bitbucket.org/Daniel Holth), ).
See pypa/pip#1922
Original report by Kevin Horn (Bitbucket: khorn, GitHub: khorn).
Given an installed "legacy" distribution (unzipped) installed via pip into a virtualenv, you get files in installed in multiple places, like so:
#!
\Lib\site-packages
|
+---plumbum
| cli.py
| cli.pyc
| commands.py
| commands.pyc
| lib.py
| lib.pyc
| local_machine.py
| local_machine.pyc
| path.py
| path.pyc
| remote_machine.py
| remote_machine.pyc
| remote_path.py
| remote_path.pyc
| session.py
| session.pyc
| unixutils.py
| unixutils.pyc
| utils.py
| utils.pyc
| version.py
| version.pyc
| __init__.py
| __init__.pyc
|
\---plumbum-1.0.1-py2.7.egg-info
dependency_links.txt
installed-files.txt
PKG-INFO
requires.txt
SOURCES.txt
top_level.txt
EggInfoDistribution.list_installed_files() lists only the files in the .egg-info directory. This sort of makes sense, and that egg-info directory is the path attribute of the distribution, but also seems odd to me, since I asked for the installed files, and instead only got some of them.
Should EggInfoDistribution.list_installed_files() instead return the contents of the installed-files.txt that resides in the egg-info directory?
Original report by Paul Moore (Bitbucket: pmoore, GitHub: pmoore).
The original report had attachments: pip-1.5.dev1-py2.py3-none-any.whl
When I try to do distil install pip pointing at a --local-dists directory that only contains a 1.5 prerelease wheel, I get an error "Checking requirements for None ... expected string or buffer" if I don't specify --pre. The error message in this case should be clearer ("Only prereleases are available and --pre is not specified" for example).
Also, when I do specify --pre, I get an odd error "invalid expression: extra". See the transcript below:
>distil -e xxyyzz --local-dists C:\Work\Projects\virtualenv-pfm\virtualenv_support install --pre pip
Checking requirements for pip (1.5.dev1) ... done.
invalid expression: extra
Actually, a third issue is that when installing pip 1.5.dev1, the executables are not being installed.
Original report by Donald Stufft (Bitbucket: dstufft, GitHub: dstufft).
Is there any reason to catch exceptions in the generated scripts? If you don't catch them Python will handle printing them, give a full stack trace, and give a non zero exit code.
As far as I can tell there's no point to this? All it does is add complication to the script and possibly have surprising behavior.Is there any reason not to just let Python handle the exception?
Original report by Donald Stufft (Bitbucket: dstufft, GitHub: dstufft).
Using the distlib ScriptMaker it appears that it makes scripts on *nix that are not executable unless you set the set_mode attribute to True before trying to create scripts. Surely this should True by default, at least on *nix?
Original report by C Anthony Risinger (Bitbucket: anthonyrisinger, GitHub: anthonyrisinger).
upon revisiting i think distil would work pretty well for my project, but i really want to install distil itself at the end of the day like a normal dist, ie. via a standard source url.
my users are other developers, as such they require an installation tool to try new libraries/etc.
while i understand the reasons for reluctance, would it be possible to make distil a first class citizen along with distlib?
i a push bugfixes/features upstream pretty diligently -- anything useful heads this way ASAP! alas, the lack of a repo is disrupting my workflow (tools!) enough to make for less-than-unfriendly debug/learning/introspection cycles...
distil can exist as a bundle, but should (IMO) first support a standard install like any other dist (eg, uses existing distlib)
in addition to above, i ask because distil.py appears months out of date, possibly back to early may...?
Original report by Paul Moore (Bitbucket: pmoore, GitHub: pmoore).
The code that locates the Windows executable launchers for ScriptMaker uses finder as follows:
result = finder('distlib').find(name).bytes
This does not work when distlib is not directly available, but is vendored (as pip does, making distlib available as pip.vendor.distlib).
This is probably fixable by not hardcoding the name 'distlib', but rather obtaining it from __name__. Using __name__[:-8] seems to work, but it's a pretty ugly hack...
Original report by Paul Moore (Bitbucket: pmoore, GitHub: pmoore).
In Wheel.build, the code starts by checking if the build is a pure-python distribution. When it does so, it should set the Python version on the wheel appropriately - at the moment it is always set to pyXY.
This needs to be done in such a way that the user can override the default in advance. In contrast, at the moment, the abi and arch values cannot be overridden, as they are set unconditionally in build().
Original report by Marc Abramowitz (Bitbucket: msabramo, GitHub: msabramo).
(py27.venv)marca@marca-mac:~/dev/hg-repos/distlib$ PYTHONHASHSEED=0 python setup.py test
running test
...........................................................................F......................................ss.ss......s.....s........................s.........s..............s.........s..........s..........
======================================================================
FAIL: test_dependency_finder (test_locators.LocatorTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "tests/test_locators.py", line 223, in test_dependency_finder
self.assertIn(tuple(names), expected)
AssertionError: (u'py', u'hgtools', u'pytest-runner', u'pytest', u'irc') not found in set([(u'hgtools', u'py', u'pytest', u'pytest-runner', u'irc'), (u'py', u'hgtools', u'pytest', u'pytest-runner', u'irc'), (u'hgtools', u'py', u'pytest-runner', u'pytest', u'irc')])
----------------------------------------------------------------------
Ran 213 tests in 91.042s
FAILED (failures=1, skipped=11)
(py32.venv)marca@marca-mac:~/dev/hg-repos/distlib$ PYTHONHASHSEED=0 python setup.py test
running test
...........................................................................F......................................ss.ss......s.....s........................s.........s..............s........ss.s.......ss..........
======================================================================
FAIL: test_dependency_finder (test_locators.LocatorTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "tests/test_locators.py", line 223, in test_dependency_finder
self.assertIn(tuple(names), expected)
AssertionError: ('py', 'hgtools', 'pytest-runner', 'pytest', 'irc') not found in {('hgtools', 'py', 'pytest', 'pytest-runner', 'irc'), ('py', 'hgtools', 'pytest', 'pytest-runner', 'irc'), ('hgtools', 'py', 'pytest-runner', 'pytest', 'irc')}
----------------------------------------------------------------------
Ran 213 tests in 66.838s
FAILED (failures=1, skipped=14)
Original report by Anonymous.
Creating a script wrapper generates a single exe file. But the exe relies on the existence of a xxx-script.py file. Presumably this is a remnant of the older approach that had an exe and a script alongside each other.
>python
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from distlib.scripts import ScriptMaker
>>> maker = ScriptMaker('.', '.')
>>> maker.make('xx = http.server:main')
['.\\xx-3.3.exe', '.\\xx.exe']
>>> ^Z
(test1) PS 13:57 C:\Work\Scratch
>dir xx*
Directory: C:\Work\Scratch
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 29/12/2013 13:57 93979 xx-3.3.exe
-a--- 29/12/2013 13:57 93979 xx.exe
(test1) PS 13:57 C:\Work\Scratch
>.\xx.exe
Fatal error in launcher: Failed to open script file "C:\Work\Scratch\xx-script.py"
See also pypa/pip#1403 - this is a release blocker for pip.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.