Most upload source and wheel to support both flavors: $ python setup.py register -r pypi $ python setup.py sdist upload -r pypi $ python setup.py bdist_wheel upload -r pypi
On Sat, Oct 18, 2014 at 9:07 PM, Jake Farrell <jfarr...@apache.org> wrote: > I can do nuget during the release process, please add me as a maintainer. > wheel is a nice thought, but might not work for other projects using our > lib and its been easiest to publish the src to pypi and let it be picked up > and installed that way (received complaints when we published binaries > before) > > -Jake > > On Sat, Oct 18, 2014 at 5:48 PM, Randy Abernethy <r...@apache.org> wrote: > >> Hey All, >> >> The package manager topic Jens raises is an interesting >> one, especially close to the 0.9.2 release. As I understand >> it we have two kinds of package managers to deal with. >> >> 1. Those that pull source from the apache/thrift github repo >> 2. Those that we build libs for and upload to a central repo >> >> The type 1s I know of are: >> - Front End JavaScript (Bower) >> - Node.js (npm) >> - Php (Composer/Packagist) >> - Haxe (as soon as Jens adds it) >> >> The type 2s I know of are: >> - Java (through Maven which covers all JVM) >> - C# (through NuGet which covers all .Net/Mono) >> - Ruby (RubyGems.org) >> - Python (PyPI) >> >> Are there any I missed? >> >> While there's a lot to manage at release time already, I'd >> like to see thrift add a couple more release components: >> >> 1. Publishing a .Net lib to NugGet with every release >> 2. Adding Wheel to the Python publishing process >> >> I currently maintain the ApacheThrift NuGet package but >> would like to see it or its equivalent end up in the release >> process. The Wheel addition for Python should be a >> straight forward tweak to the current process. >> >> Thoughts? Anything we need to add that I missed? >> >> -Randy >> >> On Sat, Oct 18, 2014 at 5:59 AM, Jake Farrell <jfarr...@apache.org> wrote: >> > I'm not a fan of all of these extra files in the root directory, but the >> > ones that are there are due to the limitations of the client lib third >> > party packaging tools in use. We have had this discussion before, and >> > rather than splitting the Thrift repo up into compiler and each >> individual >> > client lib in a repo we choose to just put the couple of extra files in >> the >> > root directory, not the greatest but what we are stuck with right now. >> > There is already an open ticket for adding Chocolatey support, will look >> at >> > for the 0.9.2 release >> > >> > -Jake >> > >> > On Sat, Oct 18, 2014 at 4:33 AM, Jens Geyer <jensge...@hotmail.com> >> wrote: >> > >> >> Hi Randy, >> >> >> >> yes that was the assumption: that the relevant library subdir is cloned >> >> only. IMHO it makes less sense to have the full source tree after doing >> a >> >> nuget installation, I'm only interested in a part of it. I will put it >> in >> >> lib/haxe then. >> >> >> >> Re the list: add Chocolatey >> >> >> >> Thanks + have fun >> >> JensG >> >> >> >> >> >> >> >> ________________________________ >> >> Von: Randy Abernethy >> >> Gesendet: 18.10.2014 02:41 >> >> An: dev@thrift.apache.org >> >> Betreff: Re: library registration files >> >> >> >> Hey Jens, >> >> >> >> We should definitely have a strategy for all of this stuff. One >> >> difficulty is the requirements of the various language library >> >> managers. Some notes: >> >> >> >> - /bower.json - Front End JavaScript >> >> This file supports the Bower (http://bower.io/) package manager. Bower >> >> requires the bower.json to be in the root of the repo. This is pretty >> >> messed up for us because it also causes bower to clone the entire >> >> thrift repo(!). It works but hopefully bower will add functionality to >> >> pull the package manager file or at least the sources from a subdir. >> >> The /lib/js/Gruntfile.js is not a package manager file but rather the >> >> "makefile" for our JavaScript lib. The Grunt tool uses it to build, >> >> run tests, etc. The output of the Gruntfile build is >> >> /lib/js/dist/thrift.js and /lib/js/dist/thrift.min.js. The >> >> package.json found in the js dir is the package file for Grunt which >> >> is a node.js program. >> >> >> >> - /composer.json - PHP >> >> The php Packagist web site requires this file to be in the root of the >> >> repo but at least it only clones the lib/php/lib. >> >> >> >> - /lib/nodejs/package.json - Node.js >> >> This is the package manager file for npm. Fortunately the npm site >> >> allows us to point to a package file in a subdir of the repo. >> >> >> >> So in summary, you are totally right, all of these should be in their >> >> respective subdirs. Unfortunately circumstances disallow it. If you >> >> can get Haxe working with the package file in the lib dir, I think >> >> that is the right way to go. >> >> >> >> -Randy >> >> >> >> On Fri, Oct 17, 2014 at 5:02 PM, Jens Geyer <jensge...@hotmail.com> >> wrote: >> >> > Hi *, >> >> > >> >> > there are a accumulating number of registration files (mostly JSON) >> for >> >> the various package managers of this world of ours spread across the >> source >> >> tree. I found these (please correct me if I’m wrong): >> >> > >> >> > /bower.json >> >> > /composer.json >> >> > /doap.rdf >> >> > /lib/js/Gruntfile.js >> >> > /lib/js/package.json >> >> > /lib/nodejs/package.json >> >> > >> >> > Couldn’t find: >> >> > - the nuget spec file for the nuget package >> >> > >> >> > Let’s say, I would like to add another file, specifically for >> >> http://haxelib.org. My most natoral choice would be the /lib/haxe >> folder. >> >> But shouldn’t we then consequently also move composer.json into /lib/php >> >> and bower.json into /lib/nodejs? >> >> > >> >> > Or am I wrong and I should place the file in the root? What’s the >> >> consensus here? >> >> > >> >> > Have fun, >> >> > JensG >> >> > >> >> > >> >> >>
