Hello,
What's the preferred approach to having different eggs (for different
platforms) in one folder?
I noticed that fortunately easy_install recognizes the platform, so I
can get away by having good filenames, such as
mytest-2.1.2c1-py2.7-win32
mytest-2.1.2c1-py2.7-win-amd64
The problem is that the egg-generation does not include the platform
name (so it is not compatible with the easy_install behavior, which is
weird). When I look in bdist_egg.py, I can see this:
# Compute filename of the output egg
basename = Distribution(
None, None, ei_cmd.egg_name, ei_cmd.egg_version,
get_python_version(),
self.distribution.has_ext_modules() and self.plat_name
).egg_name()
So the platform argument now is
self.distribution.has_ext_modules() and self.plat_name
Shouldn't it just be
self.plat_name
?
Would there be a workaround? I can think of giving the full name to
setup, without specifying a version:
setup(name='mytest-2.1.2c1-py2.7-win32', version = '', ...)
Thanks very much!
Martin
P.S. On an unrelated note, wouldn't it be more pythonic, and easier to
read, to include keyword arguments in the basename = Distribution(...) line?
The devpi-{server,client}-1.2 releases bring a lot of refinements
and improvements for serving and interacting with your own pypi indexes:
- devpi-server serves release files from URLs containing a MD5 hash
allowing safe serving of those files through nginx
- devpi-server's USER/INDEX urls can now be used directly with
pip/easy_install without the previously required (and still valid)
``+simple/`` suffix.
- ``devpi use --set-cfg`` reads and writes pip/easy_install
configuration files, making those installers pick up the in-use
index seemlessly. You can even do ``devpi use --always-set-cfg`` to
always set those config files when issuing a "devpi use" afterwards.
- ``devpi upload`` got many improvements:
- versioned files (git and hg) will be exported to a clean directory prior to the build step
- distutils/setup.py is now only used for building a package
- documentation upload is tied to a version now
- you can directly upload distribution files, including wheel files
- both devpi-server and devpi-client are python3.3 compatible now and
depend on a new devpi-common package which consolidates various
pypi-interaction aspects to avoid code duplication. Also,
global http proxy settings are honoured.
If you have an existing devpi-server-1.1 installation serving
your own packages you can install devpi-server>=1.2 and
migrate the data with::
devpi-server --upgrade-state [--serverdir your_server_dir]
This upgrades your server state in-place. Please make sure you
backup your serverdir ahead of doing the upgrade (default location
is ~/.devpi/server).
WARNING: ``devpi-server --gendeploy`` is deprecated and will be removed
probably in favor of just generating example config files for
nginx/supervisor/cron. Also ``devpi install`` is deprecated now
in favor of using pip/easy_install directly (see also the --set-cfg
and --always-set-cfg options).
For more information please refer to the extensive documentation at:
http://doc.devpi.net/
or check the CHANGELOG below.
have fun,
holger krekel
1.2
----------------------------
devpi-server:
- serve links to files on simple pages and index root as relative
paths so that it works more nicely with proxy-pass server setups.
fixes issue56.
- make devpi-server and devpi-common python3.3 compatible, addresses
issue57
- use system http/s proxy settings from devpi-server. fixes issue58.
- refactor locations to allow nginx serving static files more directly.
Also updated nginx template accordingly.
- rework "--upgrade-state" to detect the state version of the server dir
and create an appropriate virtualenv with a devpi-server install in order
to export data, and then import that version.
- allow to use /user/index as indexserver url for pip/easy_install by
redirecting non-json queries to /user/index/PROJ[/] to
/user/index/+simple/PROJ/
- fix submission of multi-value fields like "classifiers" or "platform"
(previously they would be wrongly collapsed to become the last value of a list)
- fix normalization import/export issue: pypi names take precendence
for defining the "real" name of a project.
- always store uploaded documentation with a version. While
"devpi upload" will make sure to pass in the version, "setup.py upload_docs"
will not pass in a version. In the latter case, devpi-server assumes
the documentation belongs to the highest yet registered release.
This change requires exporting with devpi-1.1 and importing with devpi-1.2
in order to properly store versioned docs internally.
- use types/url/metadata/validation functionality of new depdency devpi_common
- internal cleanup using pytest-flakes
- make devpi-server use a proper UserAgent string
devpi-client:
- "devpi list" and "devpi remove" now accept a pip/setuptools style
requirement like "pkg>=1.0" instead of the former for limited "pkg-1.0".
- make devpi-client fully work with python3.3 and fix test bugs
- use system http/s proxy settings. fixes issue58.
- add "devpi test -c tox.ini package" to use a particular (external)
tox.ini for running tox with the unpackaged package.
also add "--fallback-ini tox.ini" option which will only
be used if the download package has no tox.ini.
- new "devpi use --set-cfg" option to set pip/easy_install configuration
files when changing indexes. Also new "devpi use --always-set-cfg=yes"
option if you want to imply "--set-cfg" on future "devpi use" invocations
and "devpi use --always-st-cfg=no" to disable this implication.
- support git and hg for exporting all versioned files of a directory
before performing the build step when uploading
- improve how upload works: setup.py is only used for building docs
and release files but not for the remote upload part. This gets rid of a
number of hacks that were done trying to get the Python shipped "distutils"
to pick the proper devpi index and allows proper SSL verification on Python2.6
onwards.
- upload: show response when uploading documentation failed
- upload: allow to specify archive files as positional arguments (both files and
directories can be specified but the latter additionally require
a --upload-dirs option)
- fix issue54: upload now works on wheel files as well.
As pkginfo does not support wheels directly, we use the ``twine``
project which extends pkginfo for now.
- only show highest version in "devpi list PROJECT" output, unless
"--all" is specified.
- on upload release files: skip rather than guess packages which contain no metadata
- strike BeautifulSoup dependency and re-use vendored pip-link parser
- use types/url/metadata/validation functionality of new depdency devpi_common
- internal cleanup wrt pytest-flakes discoveries
- remove "archive" dependency in favour of a small implementation in
devpi_common
- make devpi-client use a proper UserAgent string
I've heard that there is PyPI 2.0, but I still find current PyPI code
to be very suitable for educational purposes (unlike some complicated
framework based solutions, where much of the stuff is hidden in
internals of external lib abstractions), so I continue to send fixes
to improve code base.
Please merge this one.
https://bitbucket.org/pypa/pypi/pull-request/6/remove-unused-templatetoolsp…
--
anatoly t.
I would like to remove dependency_links from pip, and ideally
also setuptools.
In implementing the ensurepip module from PEP453 I realized that
even with the ``--no-index`` flag pip was still attempting to
reach the internet. After a little bit of investigation I realized
that the reason for this was setuptools use of dependency links.
From my investigation it appears that setuptools uses these in order
to enable secure automatic installation of the ssl dependencies on
Python < 2.6.
Overall this feature is a security concern, a malicous package could
"pin" any package they want by depending on it and adding a dependency
link a version 100000. This would be more or less transparent to
the end user.
I was looking to see what sort of impact this would have. There are
currently 167,796 source files hosted on PyPI and of those files
4,005 of them have any dependency links at all. Looking at it a
different way, there are 36,070 total projects on PyPI and 411 of them
use this feature. So this is ~2% of the files or ~1% of the projects.
So it appears that this isn't a particularly popular feature, I believe
that it is a *bad* idea that inverts the expected control and should
be removed from both pip and setuptools. In setuptools case it does use
it in the only reasonable way I can imagine, however I think setuptools
should just stop trying to automatically install those dependencies
for Pythons < 2.6 and similarly to pip just print an error and expect users
to get and install them on their own. As a reminder there are very
few downloads from PyPI that are from Pythons < 2.6 [1]
[1] https://caremad.io/blog/a-look-at-pypi-downloads/
[2] https://gist.github.com/dstufft/7173539
-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Hi all,
I've been working on a project called curdling. It's a package manager for
python. It's pretty similar to pip but with a brand new design and way less
lines of code. It uses exciting concurrency technology to provide a
reliable and fast installer for Python packages.
The current feature set includes:
* Robust Concurrent model: it’s FAST!
* Really good Error Handling and Report;
* Conflict resolution for repeated requirements;
* Distributed Cache System that includes a built-in cache server;
* Simple command line interface;
* Usage of bleeding edge technology available in the Python community;
* Concurrent and Parallel, but Ctrl-C still works;
It's currently a work in progress but I'm pretty excited about its
stability and performance. There's a good amount of documentation available
at
http://clarete.github.io/curdling
This project uses both wheel and distlib packages as part of the dependency
stack. I'm working on an essay about my experience with both libraries that
I'm planning to share on another opportunity. It will probably be available
under the "Design and Implementation" section in the main website. Feel
free to check it out right now if you don't want to wait:
http://clarete.github.io/curdling/design-and-implementation.html
Any feedback is highly appreciated.
Hi Nick, all,
PEP426 and its prior related peps see project-specific metadata as part
of distribution metadata. Main examples are "project urls" such as
"home page", "repository", "issue tracker" or contact points such as
mailing lists, maintainer emails etc. However, at any point in time
there is only one set of active project urls and contact points.
Putting those into distribution files does not really make sense.
I suggest to rather define "project metadata" and make distribution
metadata reference it. Of course we then also want a simple way to
retrieve project metadata from pypi. Which could be used from tools to
tell a user where to send a mail to etc. ("pypi-report-bug warehouse" could
e.g. open the webbrowser with the create-issue page). Or from PyPI
implementations to present proper project meta info even if looking
at an older version (the project might have switched to a different
repo meanwhile etc.)
It would also make life easier for project maintainers to change project
metadata even between releases.
I feel that PEP426 is a big chance to clean up the project/distribution
metadata confusion and provide a better base for future tooling and
organising human communication and collaboration around Python software.
cheers,
holger
It seems like the download counts on PyPI aren't accurate. Though the
really useful packages seem to have higher numbers than the packages that
only apply to a specific target audience, I'm fairly certain that the
numbers are more affected by robots and such than actual users.
Recently I started a service that requires membership. In the last month,
PyPI reports 3000 downloads of the client, yet Google Analytics only
reports a handful of visits to the website. I have even less membership
signups (as expected, so soon after launch). Why are the download counts so
inflated?
What has to be done to get this to be accurate?
I've included two screenshots of PyPI and GA.
Dustin Oprea
Hello,
The IP log that shows who did what on PyPI pages shows
some IPs that have no business being there; they seem
to come from CDNs, in my case fastly and wikia.
Can this be fixed, to make this audit log useful again?
For those distutils-sig residents that don't follow python-dev, a
certain PEP was formally accepted today :)
---------- Forwarded message ----------
From: "Martin v. Löwis" <martin(a)v.loewis.de>
Date: 22 October 2013 19:33
Subject: Re: [Python-Dev] PEP 453 (ensurepip) updated
To: Nick Coghlan <ncoghlan(a)gmail.com>, "python-dev(a)python.org"
<python-dev(a)python.org>
Am 20.10.13 14:27, schrieb Nick Coghlan:
> I have posted the latest version of PEP 453 to python.org.
This version looks good to me, and I accept it for inclusion in Python 3.4.
I'd like to thank Nick for carefully editing this PEP, and I'd like to
cite it as an archetype for a well-written PEP. It's very precise, and
it elaborates on rejected proposals and the motivation for rejection.
I'd also like to thank Donald for pushing this, and for continued work
on the implementation of the PEP. I see that this all took longer than
expected (also due to my fault in providing timely reviews). I suggest
that some of the stuff that needs to be done still is delegated, so that
Donald doesn't have to do all of it.
Regards,
Martin
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I've just released version 0.1.3 of distlib on PyPI [1]. For newcomers,
distlib is a library of packaging functionality which is intended to be
usable as the basis for third-party packaging tools.
The changes in this release are as follows:
database.py:
Added support for PEP 426 JSON metadata (pydist.json).
Generalised digests to support e.g. SHA256.
Fixed a bug in parsing legacy metadata from .egg directories.
Removed duplicated code relating to parsing "provides" fields.
index.py:
Changes relating to support for PEP 426 JSON metadata (pydist.json).
locators.py:
Changes relating to support for PEP 426 JSON metadata (pydist.json).
Fixed a bug in scoring download URLs for preference when multiple URLs
are available.
The legacy scheme is used for the default locator.
Made changes relating to parsing "provides" fields.
Generalised digests to support e.g. SHA256.
If no release version is found for a requirement, prereleases are
now considered even if not explicitly requested.
markers.py:
Added support for markers as specified in PEP 426.
metadata.py:
Added support for PEP 426 JSON metadata (pydist.json). The old
metadata class is renamed to LegacyMetadata, and the (new)
Metadata class wraps the JSON format (and also the legacy format,
through LegacyMetadata).
Removed code which was only used if docutils was installed. This code
implemented validation of .rst descriptions, which is not done in
distlib.
scripts.py:
Updated the logic for writing executable files to deal as best we can
with files which are already in use and hence cannot be deleted on
Windows.
Changed the script generation when launchers are used to write a
single executable which wraps a script (whether pre-built or
generated) and includes a manifest to avoid UAC prompts on Windows.
Changed the interface for script generation options: the "make" and
"make_multiple" methods of ScriptMaker now take an optional
options dictionary.
util.py:
Added extract_by_key() to copy selected keys from one dict to another.
Added parse_name_and_version() for use in parsing "provides" fields.
Made split_filename more flexible.
version.py:
Added support for PEP 440 version matching.
Removed AdaptiveVersion, AdaptiveMatcher etc. as they don't add
sufficient value to justify keeping them in.
wheel.py:
Added wheel_version kwarg to Wheel.build API.
Changed Wheel.install API (after consultation on distutils-sig).
Added support for PEP 426 JSON metadata (pydist.json).
Added lib_only flag to install() method.
docs:
Numerous documentation updates, not detailed further here.
tests:
Numerous test refinements, not detailed further here.
other:
Corrected setup.py to ensure that executable wrappers are included.
Please try it out, and give some feedback using the issue tracker! [2]
Regards,
Vinay Sajip
[1] https://pypi.python.org/pypi/distlib/0.1.3
[2] https://bitbucket.org/pypa/distlib/issues/new
