Re: pypi submission?
On Monday, April 6, 2015 at 5:19:29 PM UTC-5, Benjamin Schollnick wrote: > Folks, > > > I'm having issues with submitting to pypi. > > > I can register and upload my package. > > > > nerv:~ Benjamin$ pip search directory_caching > Directory_Caching - A Caching library for Directories & Files > nerv:~ Benjamin$ > > > but, if you try to install it using pip: > > > > pip install directory_caching > Reading Profile from ~/dropbox/shellscripts/profile > nerv:~ Benjamin$ pip install directory_caching > Collecting directory-caching > Could not find any downloads that satisfy the requirement directory-caching > No distributions at all found for directory-caching > > Try adding the "--pre" option. If your version number is an 'alpha' or 'pre' or 'rc' version (like 1.0a1 or 1.0rc4), then pip won't install it by default ... it will only install 'released' versions (like 1.0 or 1.0.1). Adding the --pre option tells pip you actually do want the pre-release version. So: pip install --pre directory-caching > [snip] > > - Benjamin -- Dave Hein -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to deliver different source distributions for different Python versions?
On Sunday, April 5, 2015 at 8:01:22 PM UTC-5, Steven D'Aprano wrote: > On Mon, 6 Apr 2015 06:38 am, Dave Hein wrote: > > > I would like to distribute a python package with different code for > > Python 2.* than for Python 3.*. (Mostly this is because of different > > unicode string handling). > > > > There is nothing in to setuptools or PyPi that directly supports > > this scenario. > > > > But perhaps there could be some script run at install time that moves > > the correct source code to the right location? In other works, if I > > included both source code versions in the distribution (in a src2 and > > a src3 subdirectory) then a function invoked at install time could > > detect the python version and copy the appropriate source code to the > > right location. > > > > Is that at all possible? Is there some install time hook that lets me > > supply custom installation code? > > I'm not aware of any standard solution to that, but I'm not a setuptools > expert. setup.py files are Python code, so you can put any code you like in > them. But, as far as I am concerned, having the installer pick and choose > what source files to include is not a good solution. Instead, you should > pick one of these two alternatives: > > > (1) Supply a separate package for 2.x and 3.x, each with their own > installer. The installer confirms that it is running under the correct > version of Python, and just installs. > Yep. That's what I'm doing now. Two distinct packages on PyPi. > > (2) Or supply a single package with a single installer that works under both > 2.x and 3.x. (This is my preference.) > > One way of handling the second case is to only support 3.3 or better: that > way, you can still use u"..." for Unicode strings. Hardly anyone used 3.1 > or 3.2, and 3.0 is no longer supported, so it is quite reasonable to insist > people upgrade to 3.3. > There is other code that doesn't translate cleanly between 2.x and 3.x. Specifically the unittest tests and unittest.mock usage. That's mainly why I don't have one source tree. > Another way to handle the second case is to use conditional imports: Hmm. Maybe I can figure out how to isolate the 2.x weirdness into a separate package and conditionally import the 3.x version vs. 2.x version. I'll look into that. Thanks. > [snip] > > -- > Steven -- Dave Hein -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to deliver different source distributions for different Python versions?
On Monday, April 6, 2015 at 12:47:05 AM UTC-5, Stefan Behnel wrote: > Dave Hein schrieb am 05.04.2015 um 22:38: > > I would like to distribute a python package with different code for > > Python 2.* than for Python 3.*. (Mostly this is because of different > > unicode string handling). > > > > There is nothing in to setuptools or PyPi that directly supports > > this scenario. > > > > But perhaps there could be some script run at install time that moves > > the correct source code to the right location? In other works, if I > > included both source code versions in the distribution (in a src2 and > > a src3 subdirectory) then a function invoked at install time could > > detect the python version and copy the appropriate source code to the > > right location. > > > > Is that at all possible? Is there some install time hook that lets me > > supply custom installation code? > > Sure. You can simply change the directory in which distutils looks for your > Python code: > > https://docs.python.org/2/distutils/setupscript.html#listing-whole-packages > > However, in general, you shouldn't be doing this. It's usually easier > (definitely in the long-term) to keep your sources cross-Py2.x/3.x > compatible, maybe with the help of tools like "six" or "python-future", > than to try to keep separate source trees in sync. > > http://python-future.org/ > > Stefan I understand. What got me going down the two-source-trees path is that the unittest support isn't cross compatible ... the way I'm using mocks doesn't translate between 2.7 and 3.3. I also like having really clean 3.x code and just keeping the warts confined to the 2.x branch. I use the futures stuff in the 2.x branch to keep it as close as possible to the 3.x branch, but there are still enough differences that I have to mung the 3.x changes just a little when I merge them back into the 2.x branch. -- Dave Hein -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to deliver different source distributions for different Python versions?
On Sunday, April 5, 2015 at 10:28:55 PM UTC-5, Mark Lawrence wrote: > On 05/04/2015 21:38, Dave Hein wrote: > > I would like to distribute a python package with different code for > > Python 2.* than for Python 3.*. (Mostly this is because of different > > unicode string handling). > > > > There is nothing in to setuptools or PyPi that directly supports > > this scenario. > > > > But perhaps there could be some script run at install time that moves > > the correct source code to the right location? In other works, if I > > included both source code versions in the distribution (in a src2 and > > a src3 subdirectory) then a function invoked at install time could > > detect the python version and copy the appropriate source code to the > > right location. > > > > Is that at all possible? Is there some install time hook that lets me > > supply custom installation code? > > > > -- > > Dave Hein > > > > I can't help directly but have you looked here > https://packaging.python.org/en/latest/ ? Yep. I looked there first and from that thought that I could distribute "wheels" -- a 2.7 wheel, a 3.3 wheel, and a 3.4 wheel. But the latest setup.py (version 15.0) doesn't build wheels anymore. It does build binary distributions, but they are tied more to a particular version of a particular OS rather than to a particular version of Python. So, anyway, I think parts of that documentation site are out of date. And I didn't see anything that let me do what I wanted. > > -- > My fellow Pythonistas, ask not what our language can do for you, ask > what you can do for our language. > > Mark Lawrence -- Dave Hein -- https://mail.python.org/mailman/listinfo/python-list
Is it possible to deliver different source distributions for different Python versions?
I would like to distribute a python package with different code for Python 2.* than for Python 3.*. (Mostly this is because of different unicode string handling). There is nothing in to setuptools or PyPi that directly supports this scenario. But perhaps there could be some script run at install time that moves the correct source code to the right location? In other works, if I included both source code versions in the distribution (in a src2 and a src3 subdirectory) then a function invoked at install time could detect the python version and copy the appropriate source code to the right location. Is that at all possible? Is there some install time hook that lets me supply custom installation code? -- Dave Hein -- https://mail.python.org/mailman/listinfo/python-list
