I have now made my first wheel release as the new maintainer.
This release contains bug fixes and documentation updates. I decided to
make a release now to get a fix out for some long standing issues. A
proper overhaul of the documentation is coming later.
The project has also been migrated from Bitbucket to Github
I'm currently using Linux Mint 18.2 "Sonya" (Cinnamon-64) and Python
there're two versions installed by default on my system: *Python 2.7.12*
and *Python 3.5.2* (picture bellow).
[image: Imagem inline 2]
I would like to install the latest Python version (3.6.2). As far as I
know, I can't install it over Python 2. However, I would like to know if I
can install the 3.6.2 over 3.5.2. If that's possible, how can I do that?
Thanks in advance.
I am trying to install jpredapi in python 2.1 using command python -m pip
install jpreadapi but getting an error
Can you please help me in this?
Institute of Bioinformatics and Biotechnology(iBB),
Savitribai Phule Pune University.
i'd like to propose a common tooling for installing packages in editable
which is based on generating an actual wheel, which includes shim files
for the python packages
allows to sanely instal/uninstall editable packages
a while back i implemented a prototype in gumby-elf which serves as my
i'd like to start a discussion on this, and hopefully ensure that tools
like flit and setuptools adapt a similar mechanism, ideally sharing a
once this discussion is finished i'd also like to implement it for
On Mon, Sep 4, 2017 at 6:00 AM, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
> >> Do the Linux distros use pip to build their packages?
> > Not that I am aware of.
> Fedora's build macros for Python projects currently rely on running
> setup.py directly, but we've been considering switching to pip instead
> since 2013 or so. PEP 517 is likely to provide the impetus to switch
> from "maybe we should do that" to "we need to do that, at least if
> setup.py is missing, and potentially always, so we get more consistent
> installation metadata"
which is exactly why I tried to do it in conda. In a post PEP 517 world,
that may be a good way to go. I'm looking forward to it.
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Quick question about an arcane topic: currently, PEP 517 says that
paths are always represented as unicode strings. For example, when the
frontend calls build_wheel, it has to create a temporary dir to hold
the output wheel, and it passes this in as an absolute path
represented as a unicode string.
In Python 3 I think this is totally fine, because the surrogate-escape
system means that all paths can be represented as unicode strings,
even on systems like Linux where you can have paths that are invalid
according to Python's idea of the filesystem encoding.
In Python 2, if I understand correctly (and I'm not super confident
that I do), then there is no surrogate-escape, and it's possible to
have paths that can't be represented as a unicode object. For example,
if someone's home directory is /home/stéfan in UTF-8 but Python thinks
that the locale is C, and a frontend tries to make a tmpdir in
$HOME/.local/tmp/ and pass it to a backend then... everything blows
up, I guess?
So I guess this is a question for those unfortunate souls who
understand these details better than me (hi Nick!): is this actually a
problem, and is there anything we can/should do differently?
Nathaniel J. Smith -- https://vorpus.org