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 > >> > > >> > > >> >
