date:20140828

Re: [Distutils] defining requirements on pypi

2014-08-28 Thread Vinay Sajip

> PyPI won’t show metadata for Wheels either unless you upload them with Twine

Why is that, exactly? Is there something alternate tools would need to do to 
achieve the same thing?

Regards,

Vinay Sajip



 From: Donald Stufft 
To: Daniel Holth  
Cc: Brett Graham ; DistUtils mailing list 
 
Sent: Thursday, 28 August 2014, 23:11
Subject: Re: [Distutils] defining requirements on pypi
 


PyPI doesn’t parse anything, metadata is passed alongside the file upload. This 
means that for sdists it would just need modified to communicate that 
information to PyPI. PyPI won’t show metadata for Wheels either unless you 
upload them with Twine.


On Aug 28, 2014, at 6:02 PM, Daniel Holth  wrote:
>
>Pypi only parses requirements from wheels for display but this doesn't affect 
>installation.
>On Aug 28, 2014 7:49 AM, "Brett Graham"  wrote:
>
>Hi,
>>
>>
>>I feel like these are stupid questions but I cannot seem to find a straight 
>>answer.
>>
>>
>>In brief,
>>
>>
>>1) what is egg-info/requires.txt used for?
>>2) how do I properly define requirements for pypi?
>>
>>
>>The details are:
>>
>>
>>I'm updating some packages on pypi and am having difficulty defining 
>>requirements.
>>
>>
>>One of the packages in question is: pypi.python.org/pypi/jsui
>>
>>
>>I'm initially defining the requirements in a requirements.txt that then gets 
>>parsed in setup.py and install_requires gets set to the contents of 
>>requirements.txt. Some of the output from python setup.py sdist build is 
>>below. The resulting requires.txt in jsui.egg-info is:
>>
>>
>>flask
>>wsrpc
>>
>>
>>However, when I upload this to pypi with "python setup.py sdist upload" I'm 
>>not seeing these requirements listed nor does pip installing the package 
>>install the requirements.
>> 
>>Thanks for your help.
>>
>>
>> python setup.py sdist build partial output 
>>
>>
>>running sdist
>>running egg_info
>>writing requirements to jsui.egg-info/requires.txt
>>writing jsui.egg-info/PKG-INFO
>>writing top-level names to jsui.egg-info/top_level.txt
>>writing dependency_links to jsui.egg-info/dependency_links.txt
>>reading manifest file 'jsui.egg-info/SOURCES.txt'
>>writing manifest file 'jsui.egg-info/SOURCES.txt'
>>running check
>>warning: check: missing required meta-data: url
>>
>>
>>creating jsui-0.0.1
>>creating jsui-0.0.1/jsui
>>creating jsui-0.0.1/jsui.egg-info
>>making hard links in jsui-0.0.1...
>>hard linking README -> jsui-0.0.1
>>hard linking setup.py -> jsui-0.0.1
>>hard linking jsui/__init__.py -> jsui-0.0.1/jsui
>>hard linking jsui/serve.py -> jsui-0.0.1/jsui
>>hard linking jsui.egg-info/PKG-INFO -> jsui-0.0.1/jsui.egg-info
>>hard linking jsui.egg-info/SOURCES.txt -> jsui-0.0.1/jsui.egg-info
>>hard linking jsui.egg-info/dependency_links.txt -> jsui-0.0.1/jsui.egg-info
>>hard linking jsui.egg-info/requires.txt -> jsui-0.0.1/jsui.egg-info
>>hard linking jsui.egg-info/top_level.txt -> jsui-0.0.1/jsui.egg-info
>>Writing jsui-0.0.1/setup.cfg
>>Creating tar archive
>>removing 'jsui-0.0.1' (and everything under it)
>>running build
>>running build_py
>>___
>>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
>

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
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

Re: [Distutils] defining requirements on pypi

2014-08-28 Thread Donald Stufft

Send the data when they upload.

> On Aug 28, 2014, at 6:46 PM, Vinay Sajip  wrote:
> 
> > PyPI won’t show metadata for Wheels either unless you upload them with Twine
> 
> Why is that, exactly? Is there something alternate tools would need to do to 
> achieve the same thing?
> 
> Regards,
> 
> Vinay Sajip
> 
> From: Donald Stufft 
> To: Daniel Holth  
> Cc: Brett Graham ; DistUtils mailing list 
>  
> Sent: Thursday, 28 August 2014, 23:11
> Subject: Re: [Distutils] defining requirements on pypi
> 
> PyPI doesn’t parse anything, metadata is passed alongside the file upload. 
> This means that for sdists it would just need modified to communicate that 
> information to PyPI. PyPI won’t show metadata for Wheels either unless you 
> upload them with Twine.
> 
> 
>> On Aug 28, 2014, at 6:02 PM, Daniel Holth > > wrote:
>> 
>> Pypi only parses requirements from wheels for display but this doesn't 
>> affect installation.
>> On Aug 28, 2014 7:49 AM, "Brett Graham" > > wrote:
>> Hi,
>> 
>> I feel like these are stupid questions but I cannot seem to find a straight 
>> answer.
>> 
>> In brief,
>> 
>> 1) what is egg-info/requires.txt used for?
>> 2) how do I properly define requirements for pypi?
>> 
>> The details are:
>> 
>> I'm updating some packages on pypi and am having difficulty defining 
>> requirements.
>> 
>> One of the packages in question is: pypi.python.org/pypi/jsui 
>> 
>> 
>> I'm initially defining the requirements in a requirements.txt that then gets 
>> parsed in setup.py and install_requires gets set to the contents of 
>> requirements.txt. Some of the output from python setup.py sdist build is 
>> below. The resulting requires.txt in jsui.egg-info is:
>> 
>> flask
>> wsrpc
>> 
>> However, when I upload this to pypi with "python setup.py sdist upload" I'm 
>> not seeing these requirements listed nor does pip installing the package 
>> install the requirements.
>>  
>> Thanks for your help.
>> 
>>  python setup.py sdist build partial output 
>> 
>> running sdist
>> running egg_info
>> writing requirements to jsui.egg-info/requires.txt
>> writing jsui.egg-info/PKG-INFO
>> writing top-level names to jsui.egg-info/top_level.txt
>> writing dependency_links to jsui.egg-info/dependency_links.txt
>> reading manifest file 'jsui.egg-info/SOURCES.txt'
>> writing manifest file 'jsui.egg-info/SOURCES.txt'
>> running check
>> warning: check: missing required meta-data: url
>> 
>> creating jsui-0.0.1
>> creating jsui-0.0.1/jsui
>> creating jsui-0.0.1/jsui.egg-info
>> making hard links in jsui-0.0.1...
>> hard linking README -> jsui-0.0.1
>> hard linking setup.py -> jsui-0.0.1
>> hard linking jsui/__init__.py -> jsui-0.0.1/jsui
>> hard linking jsui/serve.py -> jsui-0.0.1/jsui
>> hard linking jsui.egg-info/PKG-INFO -> jsui-0.0.1/jsui.egg-info
>> hard linking jsui.egg-info/SOURCES.txt -> jsui-0.0.1/jsui.egg-info
>> hard linking jsui.egg-info/dependency_links.txt -> jsui-0.0.1/jsui.egg-info
>> hard linking jsui.egg-info/requires.txt -> jsui-0.0.1/jsui.egg-info
>> hard linking jsui.egg-info/top_level.txt -> jsui-0.0.1/jsui.egg-info
>> Writing jsui-0.0.1/setup.cfg
>> Creating tar archive
>> removing 'jsui-0.0.1' (and everything under it)
>> running build
>> running build_py
>> 
>> ___
>> 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 
>> 
> 
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
> 
> 
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org 
> 
> https://mail.python.org/mailman/listinfo/distutils-sig 
> 
> 
> 

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Handling Case/Normalization Differences

2014-08-28 Thread Nick Coghlan

On 29 Aug 2014 08:27, "Donald Stufft"  wrote:
>
>
> Just thought of this, if the normalized name doesn’t match the "real"
name,
> then add entries for both. This will make it so that pip 1.5 continues to
work
> and pip 1.6+.

Having bandersnatch mirrors publish under both names sounds like a good
approach.

Then the pip 1.6 release notes can just be explicit that using older
mirrors will need the extra option - earlier versions won't have a problem.

Cheers,
Nick.

>
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
>
> ___
> 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

Re: [Distutils] defining requirements on pypi

2014-08-28 Thread Brett Graham

Thanks for testing it and extra info!

It sounds like I 'fixed' the problem in the not-recommended way of
including requirements.txt in the MANIFEST.in.

I've been using a pretty hefty setup.py:
https://github.com/braingram/simple_setup that attempts to auto-parse and
detect 'everything' (finding packages, data, scripts, author info, version,
requirements) with the hope of dropping it in a directory with a python
module and magically having it pypi compatible. It sounds like it may be a
pipe dream :)


On Thu, Aug 28, 2014 at 2:41 PM, Marcus Smith  wrote:

>
>
>
> On Wed, Aug 27, 2014 at 2:51 PM, Brett Graham 
> wrote:
>
>> Hi,
>>
>> I feel like these are stupid questions but I cannot seem to find a
>> straight answer.
>>
>> In brief,
>>
>> 1) what is egg-info/requires.txt used for?
>> 2) how do I properly define requirements for pypi?
>>
>> The details are:
>>
>> I'm updating some packages on pypi and am having difficulty defining
>> requirements.
>>
>> One of the packages in question is: pypi.python.org/pypi/jsui
>>
>> I'm initially defining the requirements in a requirements.txt that then
>> gets parsed in setup.py and install_requires gets set to the contents of
>> requirements.txt. Some of the output from python setup.py sdist build is
>> below. The resulting requires.txt in jsui.egg-info is:
>>
>> flask
>> wsrpc
>>
>> However, when I upload this to pypi with "python setup.py sdist upload"
>> I'm not seeing these requirements listed nor does pip installing the
>> package install the requirements
>>
>
> when I install jsui from pypi, it finds and installs flask and wsrpc.
> what you've done is working.
>
> in general though, I wouldn't parse "install_requires" from a requirements
> file.
> It's mixing use cases.
>
> see the "install_requires vs requirements files" section in the Python
> Packaging User Guide
>
> https://packaging.python.org/en/latest/technical.html#install-requires-vs-requirements-files
>
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Handling Case/Normalization Differences

2014-08-28 Thread Donald Stufft

Since pip 1.4 it does yes, however the problem here is that typically 
bandersnatch
mirrors are simply hosted by plain static web servers and don’t require any 
sort of runtime logic.

> On Aug 28, 2014, at 6:39 PM, Joe Smith  wrote:
> 
> Naive question- does pip send over a UserAgent (or something) that contains a 
> version number the server can use to determine which behavior to default to?
> 
> That would allow a deprecation cycle of N months or so that will let people 
> upgrade from 1.5 to 1.6. We could then watch usage of 1.5 decrease over time 
> until it's a non-factor.
> 
> 
> On Thu, Aug 28, 2014 at 3:26 PM, Donald Stufft  > wrote:
> 
>> On Aug 28, 2014, at 6:09 PM, Donald Stufft > > wrote:
>> 
>> 
>>> On Aug 28, 2014, at 2:58 PM, Donald Stufft >> > wrote:
>>> 
>>> Right now the “canonical” page for a particular project on PyPI is whatever 
>>> the
>>> author happened to name their package (e.g. Django). This requires PyPI to 
>>> have
>>> some "smarts" so that it can redirect things like /simple/django/ to
>>> /simple/Django/ otherwise someone doing ``pip install django`` would fall 
>>> back
>>> to a much worse behavior.
>>> 
>>> If this redirect doesn't happen, then pip will issue a request for just
>>> /simple/ and look for a link that, when both sides are normalized, compares
>>> equal to the name it's looking for. It will then follow the link, get
>>> /simple/Django/ and everything works... Except it doesn't. The problem here
>>> comes from the external link classification that we have now. Pip sees the
>>> link to /simple/Django/ as an external link (because it lacks the required
>>> rels) and the installation finally fails.
>>> 
>>> The /simple/ case rarely happens when installing from PyPI itself because of
>>> the redirect, however it happens quite often when someone is attempting to
>>> instal from a mirror instead. Even when everything works correctly the 
>>> penality
>>> for not knowing exactly what name to type in results in at least 1 extra 
>>> http
>>> request, one of which (/simple/) requires pulling down a 2.1MB file.
>>> 
>>> To fix this I'm going to modify PyPI so that it uses the normalized name in
>>> the /simple/ URL and redirects everything else to the non-normalized name. 
>>> I'm
>>> also going to submit a PR to bandersnatch so that it will use normalized 
>>> names
>>> for it's directories and such as well. These two changes will make it so 
>>> that
>>> the client side will know ahead of time exactly what form the server expects
>>> any given name to be in. This will allow a change in pip to happen which
>>> will pre-normalize all names which will make the interaction with mirrors 
>>> better
>>> and will reduce the number of HTTP requests that a single ``pip install`` 
>>> needs
>>> to make.
>>> 
>>> ---
>>> Donald Stufft
>>> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>>> 
>>> ___
>>> Distutils-SIG maillist  -  Distutils-SIG@python.org 
>>> 
>>> https://mail.python.org/mailman/listinfo/distutils-sig 
>>> 
>> 
>> 
>> Hm, so here’s the problem.
>> 
>> I have this implemented and deployed to TestPyPI, it works great!
>> 
>> However, the next step is to make the change to bandersnatch so that it saves
>> things using their normalized name instead of using their "proper" name. 
>> Doing
>> this will trigger it so that everyone using pip 1.5 won't be able to install
>> anything from that mirror unless it's name is specified as the normalized 
>> name
>> (e.g. ``pip install Django`` will fail without --allow-unverified but
>> ``pip install django`` will work). This would be fixed with pip 1.6 (since
>> it would know to "normalize" the name before fetching the URL).
>> 
>> The same thing will occur if we make the change in pip first, it would
>> normalize names so you'd need to use --allow-unverified for everything 
>> because
>> it would act as if you typed ``pip install django`` instead of ``pip install
>> Django``.
>> 
>> To my knowledge, this *only* will affect pip 1.5.x.
>> 
>> So the only way forward I can see to make this change, which I think is a 
>> good
>> change and will remove a big "gotcha" from using a mirror, is to coordinate
>> a release of bandersnatch that coincides with pip 1.6, and tell people they
>> need to upgrade in lockstep.
>> 
>> Does anyone have any other ideas?
>> 
>> ---
>> Donald Stufft
>> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>> 
>> ___
>> Distutils-SIG maillist  -  Distutils-SIG@python.org 
>> 
>> https://mail.python.org/mailman/listinfo/distutils-sig 
>> 
> 
> 
> Just thought of this, if the normalized name doesn’t match the "real" name,
> then add entries for both. This will

Re: [Distutils] Handling Case/Normalization Differences

2014-08-28 Thread Joe Smith

Naive question- does pip send over a UserAgent (or something) that contains
a version number the server can use to determine which behavior to default
to?

That would allow a deprecation cycle of N months or so that will let people
upgrade from 1.5 to 1.6. We could then watch usage of 1.5 decrease over
time until it's a non-factor.


On Thu, Aug 28, 2014 at 3:26 PM, Donald Stufft  wrote:

>
> On Aug 28, 2014, at 6:09 PM, Donald Stufft  wrote:
>
>
> On Aug 28, 2014, at 2:58 PM, Donald Stufft  wrote:
>
> Right now the “canonical” page for a particular project on PyPI is
> whatever the
> author happened to name their package (e.g. Django). This requires PyPI to
> have
> some "smarts" so that it can redirect things like /simple/django/ to
> /simple/Django/ otherwise someone doing ``pip install django`` would fall
> back
> to a much worse behavior.
>
> If this redirect doesn't happen, then pip will issue a request for just
> /simple/ and look for a link that, when both sides are normalized, compares
> equal to the name it's looking for. It will then follow the link, get
> /simple/Django/ and everything works... Except it doesn't. The problem here
> comes from the external link classification that we have now. Pip sees the
> link to /simple/Django/ as an external link (because it lacks the required
> rels) and the installation finally fails.
>
> The /simple/ case rarely happens when installing from PyPI itself because
> of
> the redirect, however it happens quite often when someone is attempting to
> instal from a mirror instead. Even when everything works correctly the
> penality
> for not knowing exactly what name to type in results in at least 1 extra
> http
> request, one of which (/simple/) requires pulling down a 2.1MB file.
>
> To fix this I'm going to modify PyPI so that it uses the normalized name in
> the /simple/ URL and redirects everything else to the non-normalized name.
> I'm
> also going to submit a PR to bandersnatch so that it will use normalized
> names
> for it's directories and such as well. These two changes will make it so
> that
> the client side will know ahead of time exactly what form the server
> expects
> any given name to be in. This will allow a change in pip to happen which
> will pre-normalize all names which will make the interaction with mirrors
> better
> and will reduce the number of HTTP requests that a single ``pip install``
> needs
> to make.
>
>  ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
> Hm, so here’s the problem.
>
> I have this implemented and deployed to TestPyPI, it works great!
>
> However, the next step is to make the change to bandersnatch so that it
> saves
> things using their normalized name instead of using their "proper" name.
> Doing
> this will trigger it so that everyone using pip 1.5 won't be able to
> install
> anything from that mirror unless it's name is specified as the normalized
> name
> (e.g. ``pip install Django`` will fail without --allow-unverified but
> ``pip install django`` will work). This would be fixed with pip 1.6 (since
> it would know to "normalize" the name before fetching the URL).
>
> The same thing will occur if we make the change in pip first, it would
> normalize names so you'd need to use --allow-unverified for everything
> because
> it would act as if you typed ``pip install django`` instead of ``pip
> install
> Django``.
>
> To my knowledge, this *only* will affect pip 1.5.x.
>
> So the only way forward I can see to make this change, which I think is a
> good
> change and will remove a big "gotcha" from using a mirror, is to coordinate
> a release of bandersnatch that coincides with pip 1.6, and tell people they
> need to upgrade in lockstep.
>
> Does anyone have any other ideas?
>
>  ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
> Just thought of this, if the normalized name doesn’t match the "real" name,
> then add entries for both. This will make it so that pip 1.5 continues to
> work
> and pip 1.6+.
>
>  ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
>
> ___
> 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

Re: [Distutils] Undefined symbol when loading a library using dlopen

2014-08-28 Thread Erik Bray

On Tue, Aug 26, 2014 at 5:54 PM, Jerome Fuselier
 wrote:
> Hello,
>
> I'm trying to wrap a C++ library which uses dlopen to load a dynamic library
> and I don't manage to get rid of an "undefined symbol" error.
>
> I tried to simulate my problem with a simpler example so hopefully someone
> may be able to tell me what I'm doing wrong.
>
> I have a file func.cpp which provides 2 functions :
>
> func.cpp:
>
> int simple(void) {
> return 12;
> }
>
> int call_lib(void) {
> int res;
> void *handle = dlopen("/home/jerome/Test/libDyn.so", RTLD_NOW);
>
> if (!handle) {
> return -1;
> }
> dlerror();
> char* err = 0;
> int (*fun_dyn)() = (int (*)())dlsym(handle, "fun_dyn");
> if ( (err = dlerror()) != 0 ) {
> dlclose(handle);
> return -1;
> }
> res = (*fun_dyn)();
> dlclose(handle);
> return res;
> }
>
> It is created like that:
> $ g++ -Wall -g -fPIC -c -o func.o func.cpp
> $ ar rcs libFun.a func.o
>
> I have a dynamic library which is called from call_lib() which depends on
> libFun.a:
>
> libDyn.cpp:
>
> #include "func.hpp"
>
> int fun_dyn(void) {
> return simple();
> }
>
> It is created like that:
> $ g++ -Wall -g -fPIC -c -o libDyn.o libDyn.cpp
> $ g++ -Wall -g -fPIC -shared -o libDyn.so libDyn.o
>
> I'm using swig to wrap the libFun.a library with this mylib.i interface
> file:
>
> %module mylib
>
> int simple(void);
> int call_lib(void);
>
> Then I'm using this setup.py file to create the Python module:
>
> from distutils.core import setup, Extension
>
> mylib = Extension("_mylib",
>   sources=['mylib.i'],
>   language="c++",
>   extra_link_args=['-rdynamic'],
>   libraries=["Fun", "dl"],
>  )
>
> setup(name="MyLib",
>   platforms=["Linux"],
>   ext_modules=[mylib],
>   py_modules = ["mylib"])
>
>
> It's a simplified example but when I compile everything I get this error in
> Python:
 import _mylib
 _mylib.call_lib()
> failed to open shared object file
> /home/jerome/Test/libDyn.so: undefined symbol: simple
>
> If I do a nm _mylib.so I see that the symbol simple is present in the
> library so I'm wondering why dlopen doesn't see it when it tries to load the
> library.
>
> I know I can recompile libDyn.so to link libFun.a but this would means I
> would need to recompile all the plugins provided for the library I'm trying
> to wrap and that's not really a solution for my project.

I don't think this question really has to do with distutils' role in
this.  But have you tried declaring

extern "C" {
int simple(void);
}

in func.cpp?  I think that should do it (to get around C++ name mangling).

Best of luck,

Erik
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Handling Case/Normalization Differences

2014-08-28 Thread Donald Stufft


> On Aug 28, 2014, at 6:09 PM, Donald Stufft  wrote:
> 
> 
>> On Aug 28, 2014, at 2:58 PM, Donald Stufft > > wrote:
>> 
>> Right now the “canonical” page for a particular project on PyPI is whatever 
>> the
>> author happened to name their package (e.g. Django). This requires PyPI to 
>> have
>> some "smarts" so that it can redirect things like /simple/django/ to
>> /simple/Django/ otherwise someone doing ``pip install django`` would fall 
>> back
>> to a much worse behavior.
>> 
>> If this redirect doesn't happen, then pip will issue a request for just
>> /simple/ and look for a link that, when both sides are normalized, compares
>> equal to the name it's looking for. It will then follow the link, get
>> /simple/Django/ and everything works... Except it doesn't. The problem here
>> comes from the external link classification that we have now. Pip sees the
>> link to /simple/Django/ as an external link (because it lacks the required
>> rels) and the installation finally fails.
>> 
>> The /simple/ case rarely happens when installing from PyPI itself because of
>> the redirect, however it happens quite often when someone is attempting to
>> instal from a mirror instead. Even when everything works correctly the 
>> penality
>> for not knowing exactly what name to type in results in at least 1 extra http
>> request, one of which (/simple/) requires pulling down a 2.1MB file.
>> 
>> To fix this I'm going to modify PyPI so that it uses the normalized name in
>> the /simple/ URL and redirects everything else to the non-normalized name. 
>> I'm
>> also going to submit a PR to bandersnatch so that it will use normalized 
>> names
>> for it's directories and such as well. These two changes will make it so that
>> the client side will know ahead of time exactly what form the server expects
>> any given name to be in. This will allow a change in pip to happen which
>> will pre-normalize all names which will make the interaction with mirrors 
>> better
>> and will reduce the number of HTTP requests that a single ``pip install`` 
>> needs
>> to make.
>> 
>> ---
>> Donald Stufft
>> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>> 
>> ___
>> Distutils-SIG maillist  -  Distutils-SIG@python.org 
>> 
>> https://mail.python.org/mailman/listinfo/distutils-sig 
>> 
> 
> 
> Hm, so here’s the problem.
> 
> I have this implemented and deployed to TestPyPI, it works great!
> 
> However, the next step is to make the change to bandersnatch so that it saves
> things using their normalized name instead of using their "proper" name. Doing
> this will trigger it so that everyone using pip 1.5 won't be able to install
> anything from that mirror unless it's name is specified as the normalized name
> (e.g. ``pip install Django`` will fail without --allow-unverified but
> ``pip install django`` will work). This would be fixed with pip 1.6 (since
> it would know to "normalize" the name before fetching the URL).
> 
> The same thing will occur if we make the change in pip first, it would
> normalize names so you'd need to use --allow-unverified for everything because
> it would act as if you typed ``pip install django`` instead of ``pip install
> Django``.
> 
> To my knowledge, this *only* will affect pip 1.5.x.
> 
> So the only way forward I can see to make this change, which I think is a good
> change and will remove a big "gotcha" from using a mirror, is to coordinate
> a release of bandersnatch that coincides with pip 1.6, and tell people they
> need to upgrade in lockstep.
> 
> Does anyone have any other ideas?
> 
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
> 
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig


Just thought of this, if the normalized name doesn’t match the "real" name,
then add entries for both. This will make it so that pip 1.5 continues to work
and pip 1.6+.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Handling Case/Normalization Differences

2014-08-28 Thread Donald Stufft

> On Aug 28, 2014, at 2:58 PM, Donald Stufft  wrote:
> 
> Right now the “canonical” page for a particular project on PyPI is whatever 
> the
> author happened to name their package (e.g. Django). This requires PyPI to 
> have
> some "smarts" so that it can redirect things like /simple/django/ to
> /simple/Django/ otherwise someone doing ``pip install django`` would fall back
> to a much worse behavior.
> 
> If this redirect doesn't happen, then pip will issue a request for just
> /simple/ and look for a link that, when both sides are normalized, compares
> equal to the name it's looking for. It will then follow the link, get
> /simple/Django/ and everything works... Except it doesn't. The problem here
> comes from the external link classification that we have now. Pip sees the
> link to /simple/Django/ as an external link (because it lacks the required
> rels) and the installation finally fails.
> 
> The /simple/ case rarely happens when installing from PyPI itself because of
> the redirect, however it happens quite often when someone is attempting to
> instal from a mirror instead. Even when everything works correctly the 
> penality
> for not knowing exactly what name to type in results in at least 1 extra http
> request, one of which (/simple/) requires pulling down a 2.1MB file.
> 
> To fix this I'm going to modify PyPI so that it uses the normalized name in
> the /simple/ URL and redirects everything else to the non-normalized name. I'm
> also going to submit a PR to bandersnatch so that it will use normalized names
> for it's directories and such as well. These two changes will make it so that
> the client side will know ahead of time exactly what form the server expects
> any given name to be in. This will allow a change in pip to happen which
> will pre-normalize all names which will make the interaction with mirrors 
> better
> and will reduce the number of HTTP requests that a single ``pip install`` 
> needs
> to make.
> 
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
> 
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

Hm, so here’s the problem.

I have this implemented and deployed to TestPyPI, it works great!

However, the next step is to make the change to bandersnatch so that it saves
things using their normalized name instead of using their "proper" name. Doing
this will trigger it so that everyone using pip 1.5 won't be able to install
anything from that mirror unless it's name is specified as the normalized name
(e.g. ``pip install Django`` will fail without --allow-unverified but
``pip install django`` will work). This would be fixed with pip 1.6 (since
it would know to "normalize" the name before fetching the URL).

The same thing will occur if we make the change in pip first, it would
normalize names so you'd need to use --allow-unverified for everything because
it would act as if you typed ``pip install django`` instead of ``pip install
Django``.

To my knowledge, this *only* will affect pip 1.5.x.

So the only way forward I can see to make this change, which I think is a good
change and will remove a big "gotcha" from using a mirror, is to coordinate
a release of bandersnatch that coincides with pip 1.6, and tell people they
need to upgrade in lockstep.

Does anyone have any other ideas?

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] defining requirements on pypi

2014-08-28 Thread Donald Stufft

PyPI doesn’t parse anything, metadata is passed alongside the file upload. This 
means that for sdists it would just need modified to communicate that 
information to PyPI. PyPI won’t show metadata for Wheels either unless you 
upload them with Twine.


> On Aug 28, 2014, at 6:02 PM, Daniel Holth  wrote:
> 
> Pypi only parses requirements from wheels for display but this doesn't affect 
> installation.
> 
> On Aug 28, 2014 7:49 AM, "Brett Graham"  > wrote:
> Hi,
> 
> I feel like these are stupid questions but I cannot seem to find a straight 
> answer.
> 
> In brief,
> 
> 1) what is egg-info/requires.txt used for?
> 2) how do I properly define requirements for pypi?
> 
> The details are:
> 
> I'm updating some packages on pypi and am having difficulty defining 
> requirements.
> 
> One of the packages in question is: pypi.python.org/pypi/jsui 
> 
> 
> I'm initially defining the requirements in a requirements.txt that then gets 
> parsed in setup.py and install_requires gets set to the contents of 
> requirements.txt. Some of the output from python setup.py sdist build is 
> below. The resulting requires.txt in jsui.egg-info is:
> 
> flask
> wsrpc
> 
> However, when I upload this to pypi with "python setup.py sdist upload" I'm 
> not seeing these requirements listed nor does pip installing the package 
> install the requirements.
>  
> Thanks for your help.
> 
>  python setup.py sdist build partial output 
> 
> running sdist
> running egg_info
> writing requirements to jsui.egg-info/requires.txt
> writing jsui.egg-info/PKG-INFO
> writing top-level names to jsui.egg-info/top_level.txt
> writing dependency_links to jsui.egg-info/dependency_links.txt
> reading manifest file 'jsui.egg-info/SOURCES.txt'
> writing manifest file 'jsui.egg-info/SOURCES.txt'
> running check
> warning: check: missing required meta-data: url
> 
> creating jsui-0.0.1
> creating jsui-0.0.1/jsui
> creating jsui-0.0.1/jsui.egg-info
> making hard links in jsui-0.0.1...
> hard linking README -> jsui-0.0.1
> hard linking setup.py -> jsui-0.0.1
> hard linking jsui/__init__.py -> jsui-0.0.1/jsui
> hard linking jsui/serve.py -> jsui-0.0.1/jsui
> hard linking jsui.egg-info/PKG-INFO -> jsui-0.0.1/jsui.egg-info
> hard linking jsui.egg-info/SOURCES.txt -> jsui-0.0.1/jsui.egg-info
> hard linking jsui.egg-info/dependency_links.txt -> jsui-0.0.1/jsui.egg-info
> hard linking jsui.egg-info/requires.txt -> jsui-0.0.1/jsui.egg-info
> hard linking jsui.egg-info/top_level.txt -> jsui-0.0.1/jsui.egg-info
> Writing jsui-0.0.1/setup.cfg
> Creating tar archive
> removing 'jsui-0.0.1' (and everything under it)
> running build
> running build_py
> 
> ___
> 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

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] defining requirements on pypi

2014-08-28 Thread Daniel Holth

Pypi only parses requirements from wheels for display but this doesn't
affect installation.
On Aug 28, 2014 7:49 AM, "Brett Graham"  wrote:

> Hi,
>
> I feel like these are stupid questions but I cannot seem to find a
> straight answer.
>
> In brief,
>
> 1) what is egg-info/requires.txt used for?
> 2) how do I properly define requirements for pypi?
>
> The details are:
>
> I'm updating some packages on pypi and am having difficulty defining
> requirements.
>
> One of the packages in question is: pypi.python.org/pypi/jsui
>
> I'm initially defining the requirements in a requirements.txt that then
> gets parsed in setup.py and install_requires gets set to the contents of
> requirements.txt. Some of the output from python setup.py sdist build is
> below. The resulting requires.txt in jsui.egg-info is:
>
> flask
> wsrpc
>
> However, when I upload this to pypi with "python setup.py sdist upload"
> I'm not seeing these requirements listed nor does pip installing the
> package install the requirements.
>
> Thanks for your help.
>
>  python setup.py sdist build partial output 
>
> running sdist
> running egg_info
> writing requirements to jsui.egg-info/requires.txt
> writing jsui.egg-info/PKG-INFO
> writing top-level names to jsui.egg-info/top_level.txt
> writing dependency_links to jsui.egg-info/dependency_links.txt
> reading manifest file 'jsui.egg-info/SOURCES.txt'
> writing manifest file 'jsui.egg-info/SOURCES.txt'
> running check
> warning: check: missing required meta-data: url
>
> creating jsui-0.0.1
> creating jsui-0.0.1/jsui
> creating jsui-0.0.1/jsui.egg-info
> making hard links in jsui-0.0.1...
> hard linking README -> jsui-0.0.1
> hard linking setup.py -> jsui-0.0.1
> hard linking jsui/__init__.py -> jsui-0.0.1/jsui
> hard linking jsui/serve.py -> jsui-0.0.1/jsui
> hard linking jsui.egg-info/PKG-INFO -> jsui-0.0.1/jsui.egg-info
> hard linking jsui.egg-info/SOURCES.txt -> jsui-0.0.1/jsui.egg-info
> hard linking jsui.egg-info/dependency_links.txt -> jsui-0.0.1/jsui.egg-info
> hard linking jsui.egg-info/requires.txt -> jsui-0.0.1/jsui.egg-info
> hard linking jsui.egg-info/top_level.txt -> jsui-0.0.1/jsui.egg-info
> Writing jsui-0.0.1/setup.cfg
> Creating tar archive
> removing 'jsui-0.0.1' (and everything under it)
> running build
> running build_py
>
> ___
> 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

Re: [Distutils] Packages that have problems being installed from wheels

2014-08-28 Thread Paul Moore

On 28 August 2014 21:33, Joost Molenaar  wrote:
> Question; would it help to use pkg_resources, or being able to specify 
> locations
> relative to the python interpreter prefix?

Generally, I'd recommend putting resource files in the package
directory and reading them via pkgutil.get_data (from the stdlib). The
advantage of that is that it supports non-filesystem importers (such
as zipfiles). pkg_resources lets you be a bit more flexible but at the
cost of a runtime dependency on setuptools (which I personally find
unacceptable, but YMMV). For projects that don't mind failing when run
from anything other than the filesystem, you can use package.__file__
to get the filesystem location of your package and work from there -
but that's zipfile-hostile and won't work with tools like
cx_Freeze/py2exe/bbfreeze.

If you are willing to restrict your code to only working when
installed to the actual filesystem, you could also use
sysconfig.get_path(name) to get the filesystem location of the various
distutils locations (name='data' is where data_files are located, for
example) and use that to locate your files. I'm not entirely sure why
this would be better than using pkgutil, though.

The key thing is to *not* try to force your data files into a fixed
location that you then hard-code in your application.

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Packages that have problems being installed from wheels

2014-08-28 Thread Joost Molenaar

FWIW, I did whip up a test case just now, I put it up at github[1].
The second commit works correctly, but not the first or the third.

For Ansible and Fabric, IMO it's not necessary to put the files in /usr/share.
It's just that they need somewhere to put those things and be able to get at
them at runtime.

Question; would it help to use pkg_resources, or being able to specify locations
relative to the python interpreter prefix? Or to put it in some
'standard' directory
such as .egg-info?

I run into this stuff in my own project as well. It annoys me to have to specify
the same data twice. :-) All I want to say is: these non-python are important
and I need to be able to find them somewhere at runtime. I don't really care
much where exactly they are.


Joost

[1] https://github.com/j0057/pydatafiles
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Packages that have problems being installed from wheels

2014-08-28 Thread Paul Moore

On 28 August 2014 20:35, Donald Stufft  wrote:
>> Both Ansible and Fabric want to put stuff in /usr/share,
>> which doesn't work from a .whl file but does from the sdist.
>
> This should be possible I think, that’s just the “data” scheme. Maybe
> the tooling isn’t quite set up for it?

There is an issue here, though. I don't know if it's what Ansible and
Fabric try to do, but I have seen it in the past (MoinMoin, for
instance, used to do this). Packages want to install files to
arbitrary locations, maybe places like /etc or other FHS-mandated
locations on Unix. They can do this in setup.py by hacking locations
or using absolute paths. But the packaging standards only allow for
the various scheme locations.

For example, the Ansible setup.py does:

# always install in /usr/share/ansible if specified
# otherwise use the first module path listed
if '/usr/share/ansible' in module_paths:
install_path = '/usr/share/ansible'
else:
install_path = module_paths[0]
dirs=os.listdir("./library/")
data_files = []
for i in dirs:
data_files.append((os.path.join(install_path, i),
glob('./library/' + i + '/*')))

That seems to be using absolute paths in data_files, which is
basically what I mean (a hack to force installation to an absolute
path). Joost is right that this won't install to
/usr/share in a venv, though. That's just not how the data
scheme works.

I think we need to establish a "proper" solution for this situation.

My view is that Python packaging should not support installation of
files to anywhere other than subdirectories of the scheme locations.
Doing so simply won't work with wheels as things stand, and it'll
never be cross-platform (there is no /usr on Windows, for example).
But that does mean that we explicitly don't support hacks like the
above, so we break a certain proportion of packages.

For packages that need to install to absolute locations, I would
suggest that this be handled by a post-install script, that copies the
relevant files from the package data location to the final
destination. Such a script can check if it's running on an unsupported
platform, or in a virtualenv, and handle that case appropriately.

The files will not be removed on uninstall with this proposal. But the
distribution could include a pre-uninstall script for that (are
pre-uninstall scripts a thing?) or just accept that this is a
limitation of trying to use Python packaging tools in a non-standard
manner and advise users to clean up those files manually.

Comments? Is my proposal reasonable? Does anyone have an alternative
to suggest? Would Ansible, Fabric and any other projects using the
current hacks be willing to migrate to post-install scripts?

Paul.

PS Actually, installing Windows start menu shortcuts is logically the
same issue, and Windows projects have used post-install scripts to do
this for some time now - see pywin32 for an example.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Packages that have problems being installed from wheels

2014-08-28 Thread Donald Stufft

> On Aug 28, 2014, at 3:24 PM, Joost Molenaar  wrote:
> 
> On Aug 27, 2014 8:50 AM, "Paul Moore"  wrote:
>> 
>> tl; dr; If you know of a project that can't be successfully installed
>> with "pip wheel proj; pip install /path/to/the/wheel.whl" can you let
>> me know the details?
> 
> Both Ansible and Fabric want to put stuff in /usr/share,
> which doesn't work from a .whl file but does from the sdist.

This should be possible I think, that’s just the “data” scheme. Maybe
the tooling isn’t quite set up for it?

> 
> AFAICT, you need to spell out the data files redundantly in
> MANIFEST.in *and* setup(data_files=...), or the wheel won't contain
> the files.

This is correct, because these two things mean different things, MANIFEST.in
is the files that get added to the sdist itself, it has no control over what 
gets
installed whereas data_files tells distills what files to install into the data
location.

You need both because if you only have MANIFEST.in, then distills won’t
actually install the files, and if you only have data_files then the sdist won’t
actually contain the files.

> 
> I've been meaning to write up a test case to demonstrate the
> problem for a good while, but haven't got around to it yet.
> 
> HTH,
> 
> Joost Molenaar
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Packages that have problems being installed from wheels

2014-08-28 Thread Joost Molenaar

On Aug 27, 2014 8:50 AM, "Paul Moore"  wrote:
>
> tl; dr; If you know of a project that can't be successfully installed
> with "pip wheel proj; pip install /path/to/the/wheel.whl" can you let
> me know the details?

Both Ansible and Fabric want to put stuff in /usr/share,
which doesn't work from a .whl file but does from the sdist.

AFAICT, you need to spell out the data files redundantly in
MANIFEST.in *and* setup(data_files=...), or the wheel won't contain
the files.

I've been meaning to write up a test case to demonstrate the
problem for a good while, but haven't got around to it yet.

HTH,

Joost Molenaar
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Handling Case/Normalization Differences

2014-08-28 Thread Donald Stufft

Right now the “canonical” page for a particular project on PyPI is whatever the
author happened to name their package (e.g. Django). This requires PyPI to have
some "smarts" so that it can redirect things like /simple/django/ to
/simple/Django/ otherwise someone doing ``pip install django`` would fall back
to a much worse behavior.

If this redirect doesn't happen, then pip will issue a request for just
/simple/ and look for a link that, when both sides are normalized, compares
equal to the name it's looking for. It will then follow the link, get
/simple/Django/ and everything works... Except it doesn't. The problem here
comes from the external link classification that we have now. Pip sees the
link to /simple/Django/ as an external link (because it lacks the required
rels) and the installation finally fails.

The /simple/ case rarely happens when installing from PyPI itself because of
the redirect, however it happens quite often when someone is attempting to
instal from a mirror instead. Even when everything works correctly the penality
for not knowing exactly what name to type in results in at least 1 extra http
request, one of which (/simple/) requires pulling down a 2.1MB file.

To fix this I'm going to modify PyPI so that it uses the normalized name in
the /simple/ URL and redirects everything else to the non-normalized name. I'm
also going to submit a PR to bandersnatch so that it will use normalized names
for it's directories and such as well. These two changes will make it so that
the client side will know ahead of time exactly what form the server expects
any given name to be in. This will allow a change in pip to happen which
will pre-normalize all names which will make the interaction with mirrors better
and will reduce the number of HTTP requests that a single ``pip install`` needs
to make.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] defining requirements on pypi

2014-08-28 Thread Marcus Smith

On Wed, Aug 27, 2014 at 2:51 PM, Brett Graham  wrote:

> Hi,
>
> I feel like these are stupid questions but I cannot seem to find a
> straight answer.
>
> In brief,
>
> 1) what is egg-info/requires.txt used for?
> 2) how do I properly define requirements for pypi?
>
> The details are:
>
> I'm updating some packages on pypi and am having difficulty defining
> requirements.
>
> One of the packages in question is: pypi.python.org/pypi/jsui
>
> I'm initially defining the requirements in a requirements.txt that then
> gets parsed in setup.py and install_requires gets set to the contents of
> requirements.txt. Some of the output from python setup.py sdist build is
> below. The resulting requires.txt in jsui.egg-info is:
>
> flask
> wsrpc
>
> However, when I upload this to pypi with "python setup.py sdist upload"
> I'm not seeing these requirements listed nor does pip installing the
> package install the requirements
>

when I install jsui from pypi, it finds and installs flask and wsrpc.
what you've done is working.

in general though, I wouldn't parse "install_requires" from a requirements
file.
It's mixing use cases.

see the "install_requires vs requirements files" section in the Python
Packaging User Guide
https://packaging.python.org/en/latest/technical.html#install-requires-vs-requirements-files
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Packages that have problems being installed from wheels

2014-08-28 Thread Nick Coghlan

On 28 Aug 2014 05:56, "Daniel Holth"  wrote:
>
> Tell me more about setup-requires. It's nice to hear it has users. Should
we promote it to a pypa project?

That would be cool - bootstrapping as much as we can *without* metadata 2.0
has the virtue of working in many more environments :)

Cheers,
Nick.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] requirements on pypi: what is egg.info/requires.txt?

2014-08-28 Thread braingram

Hi,

I feel like these are stupid questions but I cannot seem to find a straight
answer.

In brief,

1) what is egg-info/requires.txt used for?
2) how do I properly define requirements for pypi?

The details are:

I'm updating some packages on pypi and am having difficulty defining
requirements.

One of the packages in question is: pypi.python.org/pypi/jsui

I'm initially defining the requirements in a requirements.txt that then
gets parsed in setup.py and install_requires gets set to the contents of
requirements.txt. Some of the output from python setup.py sdist build is
below. The resulting requires.txt in jsui.egg-info is:

flask
wsrpc

However, when I upload this to pypi with "python setup.py sdist upload" I'm
not seeing these requirements listed nor does pip installing the package
install the requirements.

Thanks for your help.

 python setup.py sdist build partial output 

running sdist
running egg_info
writing requirements to jsui.egg-info/requires.txt
writing jsui.egg-info/PKG-INFO
writing top-level names to jsui.egg-info/top_level.txt
writing dependency_links to jsui.egg-info/dependency_links.txt
reading manifest file 'jsui.egg-info/SOURCES.txt'
writing manifest file 'jsui.egg-info/SOURCES.txt'
running check
warning: check: missing required meta-data: url

creating jsui-0.0.1
creating jsui-0.0.1/jsui
creating jsui-0.0.1/jsui.egg-info
making hard links in jsui-0.0.1...
hard linking README -> jsui-0.0.1
hard linking setup.py -> jsui-0.0.1
hard linking jsui/__init__.py -> jsui-0.0.1/jsui
hard linking jsui/serve.py -> jsui-0.0.1/jsui
hard linking jsui.egg-info/PKG-INFO -> jsui-0.0.1/jsui.egg-info
hard linking jsui.egg-info/SOURCES.txt -> jsui-0.0.1/jsui.egg-info
hard linking jsui.egg-info/dependency_links.txt -> jsui-0.0.1/jsui.egg-info
hard linking jsui.egg-info/requires.txt -> jsui-0.0.1/jsui.egg-info
hard linking jsui.egg-info/top_level.txt -> jsui-0.0.1/jsui.egg-info
Writing jsui-0.0.1/setup.cfg
Creating tar archive
removing 'jsui-0.0.1' (and everything under it)
running build
running build_py
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] defining requirements on pypi

2014-08-28 Thread Brett Graham

Hi,

I feel like these are stupid questions but I cannot seem to find a straight
answer.

In brief,

1) what is egg-info/requires.txt used for?
2) how do I properly define requirements for pypi?

The details are:

I'm updating some packages on pypi and am having difficulty defining
requirements.

One of the packages in question is: pypi.python.org/pypi/jsui

I'm initially defining the requirements in a requirements.txt that then
gets parsed in setup.py and install_requires gets set to the contents of
requirements.txt. Some of the output from python setup.py sdist build is
below. The resulting requires.txt in jsui.egg-info is:

flask
wsrpc

However, when I upload this to pypi with "python setup.py sdist upload" I'm
not seeing these requirements listed nor does pip installing the package
install the requirements.

Thanks for your help.

 python setup.py sdist build partial output 

running sdist
running egg_info
writing requirements to jsui.egg-info/requires.txt
writing jsui.egg-info/PKG-INFO
writing top-level names to jsui.egg-info/top_level.txt
writing dependency_links to jsui.egg-info/dependency_links.txt
reading manifest file 'jsui.egg-info/SOURCES.txt'
writing manifest file 'jsui.egg-info/SOURCES.txt'
running check
warning: check: missing required meta-data: url

creating jsui-0.0.1
creating jsui-0.0.1/jsui
creating jsui-0.0.1/jsui.egg-info
making hard links in jsui-0.0.1...
hard linking README -> jsui-0.0.1
hard linking setup.py -> jsui-0.0.1
hard linking jsui/__init__.py -> jsui-0.0.1/jsui
hard linking jsui/serve.py -> jsui-0.0.1/jsui
hard linking jsui.egg-info/PKG-INFO -> jsui-0.0.1/jsui.egg-info
hard linking jsui.egg-info/SOURCES.txt -> jsui-0.0.1/jsui.egg-info
hard linking jsui.egg-info/dependency_links.txt -> jsui-0.0.1/jsui.egg-info
hard linking jsui.egg-info/requires.txt -> jsui-0.0.1/jsui.egg-info
hard linking jsui.egg-info/top_level.txt -> jsui-0.0.1/jsui.egg-info
Writing jsui-0.0.1/setup.cfg
Creating tar archive
removing 'jsui-0.0.1' (and everything under it)
running build
running build_py
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] defining requirements on pypi

Re: [Distutils] defining requirements on pypi

Re: [Distutils] Handling Case/Normalization Differences

Re: [Distutils] defining requirements on pypi

Re: [Distutils] Handling Case/Normalization Differences

Re: [Distutils] Handling Case/Normalization Differences

Re: [Distutils] Undefined symbol when loading a library using dlopen

Re: [Distutils] Handling Case/Normalization Differences

Re: [Distutils] Handling Case/Normalization Differences

Re: [Distutils] defining requirements on pypi

Re: [Distutils] defining requirements on pypi

Re: [Distutils] Packages that have problems being installed from wheels

Re: [Distutils] Packages that have problems being installed from wheels

Re: [Distutils] Packages that have problems being installed from wheels

Re: [Distutils] Packages that have problems being installed from wheels

Re: [Distutils] Packages that have problems being installed from wheels

[Distutils] Handling Case/Normalization Differences

Re: [Distutils] defining requirements on pypi

Re: [Distutils] Packages that have problems being installed from wheels

[Distutils] requirements on pypi: what is egg.info/requires.txt?

[Distutils] defining requirements on pypi

21 matches

Site Navigation

Mail list logo

Footer information