On 2018-09-14 16:39, Paul Moore wrote:
> My understanding (and I'm not an expert here, so hopefully someone
> else will confirm or correct) is that yes, the data directory is
> installed to "the installation root", which is $VIRTUAL_ENV for a
> virtualenv, and "something else" for non-virtualenvs (I think it's /
> on Unix and sys.prefix on Windows, no idea what happens for user
More precisely: it's always sys.prefix for non-user installs (which is
"/usr" not "/" on my system).
For user installs, it's site.USER_BASE which is "/home/jdemeyer/.local"
I think that this works great, I see nothing to fix here (except being
more explicit that absolute paths don't work).
On 2018-09-14 15:49, sashk wrote:
> Do I understand correctly, that when using relative paths in the
> data_files and installing package into virtual environment,
> installation prefix is sys.prefix and it is the same as $VIRTUAL_ENV?
Indeed, unless you specifically configure things in a non-default way.
So you just need to replace absolute paths by paths relative to
$VIRTUAL_ENV and your problem will be solved.
Hi all, trying to pull together a few separate discussions into a
single thread here.
The main issue is that currently PEP 508 does not provide environment
markers for GPU/CUDA availability, which leads to problems for
projects that want to provide distributions for environments with and
without GPU support.
As far as I can tell, there's been multiple suggestions to bring this
issue to distutils-sig, but no one has actually done it.
(closed) "How should Python packages depending on TensorFlow structure
(closed) "Adding gpu or cuda specification in PEP 508"
(closed) "More support for conditional installation"
(no response) "Adding gpu or cuda markers in PEP 508"
There is now a third-party project which attempts to amend this for
but this approach is somewhat fragile (depends on version numbers
being in sync), doesn't directly scale to all similar projects, and
would require maintainers for a given project to maintain _three_
separate projects, instead of just one.
I'm not intimately familiar with PEP 508, so my questions for this list:
* Is the demand sufficient to justify supporting this use case?
* Is it possible to add support for GPU Environment markers?
* If so, what would need to be done?
* If implemented, what should the transition look like for projects
What should really be included in an sdist via MANIFEST.in? Besides the
obvious files required for a functioning package (Anything not caught by
the default rules required for the package to function that is) and
obviously LICENSE.txt and similar.
A package's source tree, more often than not, includes other files such as
documentation, tests, examples, a random assortment of other text files,
etc. Should docs & tests, in particular, be included in an sdist via
MANIFEST.in? Should other files be added too? Or maybe the sdist should be
kept to a minimum?
This is not clearly discussed in the packaging guide:
The sampleproject (https://github.com/pypa/sampleproject) does seem to
include tests (Well a no-op test) and doesn't include them in the sdist.
The weekend of October 27-28, simultaneously in London, UK and New York
City, USA, Bloomberg will host a Python packaging and distribution tools
event. Please mark your calendars!
If you live in North America or Europe and would need assistance to
attend this as a mentor/helper, watch for more details in July.
If you live outside of the US or UK and would need an invitation letter
to get a visa to travel to one of these sprints, please write to Kevin
P. Fleming at Bloomberg, kpfleming AT bloomberg DOT net, and he'll start
setting you up.
Thanks to Bloomberg for their generosity. They're already a Platinum PSF
sponsor, and they'll host this, pay for a maintainers'/mentors' dinner
the night before, provide clusters of cloud virtual machines for the
attendees to use, and book and pay for some contributors' lodging and
This'll be an opportunity to advance Python packaging/distro tools,
teach new contributors (including many Bloomberg employees), and yeah,
if you want to get to know Bloomberg for career reasons, that too. :)
We hope mentors can arrive Thursday night 25 Oct, do prep, setup, and
dinner on Friday, then participate Sat-Sun, then leave Sunday evening or
We'll be putting more details on these lists (distutils-sig and
pypa-dev) and at https://wiki.python.org/psf/PackagingSprints .
Thanks to Bloomberg folks Mario Corchero and Henry Kleynhans in London
and Kevin P. Fleming in New York City for coordinating this, and thanks
especially to Mario and to Paul Ganssle for suggesting it!
I noticed that for PyPy3, the tag triples considered compatible were
(roughly; trimmed out the long list of macOS versions):
[('pp360', 'pypy3_60', 'macosx_10_13_x86_64'),
('pp360', 'none', 'macosx_10_13_x86_64'),
('py3', 'none', 'macosx_10_13_x86_64'),
('pp360', 'none', 'any'),
('pp3', 'none', 'any'),
('py360', 'none', 'any'),
('py3', 'none', 'any')]
Now the first question I have is about ('pp3', 'none', 'any'). Is this
meant to be a generic thing for any interpreter of the interpreter
implementation and major version, or is this special to CPython and PyPy3?
Question two is why isn't there a ('py35', 'none', 'any') or ('py34',
'none', 'any') and older to py30 after py3 like there is for CPython? Seems
like if they are just source then they should be compatible as much as
Question three is why isn't there a ('py35', 'none', 'macosx_10_13_x86_64')
for PyPy3 or CPython 3.7? I can't figure out what a Python- and
platform-specific wheel but agnostic to API wouldn't ever work?
And I'm assuming ('py360', 'none', 'any'), isn't legitimate since that
makes no sense. ;)