On Thu, Oct 11, 2012 at 8:37 AM, Ondřej Čertík <[email protected]> wrote:
> On Wed, Oct 10, 2012 at 7:03 PM, Aaron Meurer <[email protected]> wrote:
>> On Wed, Oct 10, 2012 at 5:45 PM, Ondřej Čertík <[email protected]> 
>> wrote:
>>> On Wed, Oct 10, 2012 at 3:14 PM, Matthew Brett <[email protected]> 
>>> wrote:
>>>> Hi,
>>>>
>>>> On Wed, Oct 10, 2012 at 7:35 PM, Ondřej Čertík <[email protected]> 
>>>> wrote:
>>>>> On Tue, Oct 9, 2012 at 10:53 PM, Aaron Meurer <[email protected]> wrote:
>>>>>> On Tue, Oct 9, 2012 at 11:43 PM, Ondřej Čertík <[email protected]> 
>>>>>> wrote:
>>>>>>> On Tue, Oct 9, 2012 at 10:42 PM, Ondřej Čertík 
>>>>>>> <[email protected]> wrote:
>>>>>>>> On Mon, Oct 8, 2012 at 11:20 PM, Aaron Meurer <[email protected]> 
>>>>>>>> wrote:
>>>>>>>>> I'm happy to announce that we finally have a release candidate for
>>>>>>>>> SymPy 0.7.2.  Go to http://code.google.com/p/sympy/downloads/list to
>>>>>>>>> see them.
>>>>>>>>>
>>>>>>>>> Please test this, and make sure that everything works.  SymPy 0.7.2
>>>>>>>>> adds support for Python 3, and we also have support for PyPy, assuming
>>>>>>>>> you are running a recent nightly.   So please test this, make sure the
>>>>>>>>> tarball includes everything it should (and nothing it shouldn't), that
>>>>>>>>> it installs, etc.  If someone could test the windows installer in
>>>>>>>>> particular, that would be great.
>>>>>>>>
>>>>>>>> So there is some problem with pip:
>>>>>>>>
>>>>>>>> ondrej@hawk:/tmp$ virtualenv-2.7 xx
>>>>>>>> New python executable in xx/bin/python
>>>>>>>> cInstalling setuptools............done.
>>>>>>>> Installing pip...............done.
>>>>>>>> ondrej@hawk:/tmp$ source xx/bin/activate
>>>>>>>> (xx)ondrej@hawk:/tmp$ pip install sympy
>>>>>>>> Downloading/unpacking sympy
>>>>>>>>   Downloading sympy-0.7.2.rc1.python3.tar.gz (5.3Mb): 5.3Mb downloaded
>>>>>>>>   Running setup.py egg_info for package sympy
>>>>>>>>     Traceback (most recent call last):
>>>>>>>>       File "<string>", line 14, in <module>
>>>>>>>>       File "/tmp/xx/build/sympy/setup.py", line 36, in <module>
>>>>>>>>         import sympy
>>>>>>>>       File "sympy/__init__.py", line 27, in <module>
>>>>>>>>         raise ImportError("It appears 2to3 has been run on the 
>>>>>>>> codebase. Use "
>>>>>>>>     ImportError: It appears 2to3 has been run on the codebase. Use
>>>>>>>> Python 3 or get the original source code.
>>>>>>>>     Complete output from command python setup.py egg_info:
>>>>>>>>     Traceback (most recent call last):
>>>>>>>>
>>>>>>>>   File "<string>", line 14, in <module>
>>>>>>>>
>>>>>>>>   File "/tmp/xx/build/sympy/setup.py", line 36, in <module>
>>>>>>>>
>>>>>>>>     import sympy
>>>>>>>>
>>>>>>>>   File "sympy/__init__.py", line 27, in <module>
>>>>>>>>
>>>>>>>>     raise ImportError("It appears 2to3 has been run on the codebase. 
>>>>>>>> Use "
>>>>>>>>
>>>>>>>> ImportError: It appears 2to3 has been run on the codebase. Use Python
>>>>>>>> 3 or get the original source code.
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>> Command python setup.py egg_info failed with error code 1 in 
>>>>>>>> /tmp/xx/build/sympy
>>>>>>>> Storing complete log in /home/ondrej/.pip/pip.log
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This actually is series *right* now, because it causes "pip install
>>>>>>>
>>>>>>> series -> serious.
>>>>>>>
>>>>>>> Ondrej
>>>>>>
>>>>>> I guess I didn't follow the right naming scheme for the tarball.
>>>>>>
>>>>>> You see, pip (easy_install too) uses an algorithm that very
>>>>>> aggressively searches websites for the most recent version of a
>>>>>> package.  It's impossible for me, as a package maintainer to change
>>>>>> this algorithm, and the only way for me to prevent it from searching
>>>>>> Google Code is to go through all old versions of SymPy on PyPI and
>>>>>> remove all references to Google Code.  See
>>>>>> http://mail.python.org/pipermail/catalog-sig/2012-June/004518.html for
>>>>>> more information.  So what's happening is that pip thinks that the
>>>>>> Python 3 0.7.2.rc1 tarball is the latest version of SymPy (for Python
>>>>>> 2).
>>>>>>
>>>>>> So on the one hand, I think we should push for this feature that I
>>>>>> requested again, because it's the only way that package maintainers
>>>>>> like myself will be truly able to prevent this kind of issue.  Namely,
>>>>>> there should be a flag in PyPI that package maintainers can check that
>>>>>> would tell pip/easy_install to only install packages from PyPI, and
>>>>>> nowhere else.
>>>>>>
>>>>>> On the other hand, for the here and now, we should figure out how to
>>>>>> name the tarballs so that pip-2 installs the Python 2 tarball and
>>>>>> pip-3 installs the Python 3 tarball.  We probably should also rename
>>>>>> the release candidate tarballs to "trick" pip into not installing them
>>>>>> in general.
>>>>>>
>>>>>> And by the way, SymPy wouldn't be the first package that isn't pip
>>>>>> installable.  Neither Pyglet nor gmpy can be installed by pip, for
>>>>>> exactly the same reason.  And I've only really ever tried installing
>>>>>> perhaps a couple dozen packages with pip.  My guess is that there are
>>>>>> tens if not hundreds of packages with this very same issue.
>>>>>
>>>>> So this looks like that pip is seriously broken... Don't worry about this 
>>>>> then.
>>>>> Let's release and then worry about this.
>>>>
>>>> Wasn't this predictable though?  Hence my previous suggestion to try
>>>
>>> Not for me. :)
>>
>> I was afraid it might happen, but I thought that there should at least
>> be a way to name the packages so that pip installs the right one in
>> Python 2 or Python 3.  In fact, I still do not know for sure that this
>> is indeed not possible, so I would like to investigate this option
>> further before giving up on it.
>>
>> I did know that pip would be installing the release candidates, but
>> there's nothing I can do about that, except rename the tarballs to
>> trick it.
>
> I released two beta version of new numpy:
>
> http://sourceforge.net/projects/numpy/files/NumPy/1.7.0b2/
> http://sourceforge.net/projects/numpy/files/NumPy/1.7.0b1/
>
> But pip is still installing the latest release:

I guess pip doesn't search that site. If you do "pip install numpy
--log log" (e.g., in a virtualenv), the log will show you  exactly
where it looks for tarballs.  In short, it crawls all websites
referenced in PyPI, including in old versions.

Aaron Meurer

>
> (xx)ondrej@hawk:/tmp$ pip install numpy
> Downloading/unpacking numpy
>   Downloading numpy-1.6.2.zip (2.9Mb): 745Kb downloaded
>
> So maybe there is some way to force pip do the right thing?
>
> Ondrej
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sympy" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/sympy?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Reply via email to