Keeping old versions at external repos is fine, no issue with us (but if they can be explained as non-ASF even better).
Thanks for fixing the package name. On Thu, Jun 22, 2017 at 10:26 AM Arthur Berezin <art...@gigaspaces.com> wrote: > btw, as we already have outdated packages on Pypi, I've asked +Limor > Shemesh > <li...@gigaspaces.com> to remove old packages so that we only have new ASF > packages available on Pypi to avoid confusion. > > > On Thu, Jun 22, 2017 at 5:22 PM Arthur Berezin <art...@gigaspaces.com> > wrote: > > > On Tue, Jun 20, 2017 at 12:26 PM Ran Ziv <r...@gigaspaces.com> wrote: > > > >> Bumping this one more time, and also copying this to the legal mailing > >> list. I'm not 100% sure that's the place for it, but perhaps someone > there > >> might be able to help. > >> > >> Thanks > >> > >> On Wed, Jun 14, 2017 at 6:17 PM, Ran Ziv <r...@gigaspaces.com> wrote: > >> > >> > Bumping this as well. > >> > > >> > On Mon, Jun 5, 2017 at 5:08 PM, Ran Ziv <r...@gigaspaces.com> wrote: > >> > > >> >> Hi Suneel, John, > >> >> > >> >> I have a few quick questions about creating a release for an > incubator > >> >> project: > >> >> > >> >> > >> >> 1) According to these links: 1 > >> >> < > >> > http://incubator.apache.org/guides/releasemanagement.html#podling-constraints > >> > > >> >> 2 > >> >> < > >> http://incubator.apache.org/incubation/Incubation_Policy.html#Releases> > >> >> Incubating projects must have "Incubating" in the "final file name". > I > >> >> might be missing something, but I assume the meaning is the final > >> tarball > >> >> (source distribution) or wheel (binary distribution) file. > >> >> This is unconventional and not compatible with PyPI - and indeed it > >> seems > >> >> like other Apache Incubator projects don't adhere to it (see Airflow > >> >> <https://pypi.python.org/pypi/apache-airflow>). > >> >> Am I missing something, or perhaps this is simply not relevant for > >> Python > >> >> projects? > >> >> > >> >> > >> >> 2) According to this > >> >> < > >> http://www.apache.org/legal/release-policy.html#licensing-documentation > >, > >> >> LICENSE and NOTICE must be located in all release packages, including > >> >> binary distributions. I've looked much into this and I couldn't find > a > >> good > >> >> way of bundling these files inside the wheel format - except for > >> manually > >> >> pushing them inside after creating the wheel perhaps. > >> >> The section speaks of a "customary location for licensing materials" > - > >> >> However, for the wheel format there's no such "customary location". > >> >> I tried looking into what other Apache projects do about this, and > >> indeed > >> >> the libcloud project doesn't have these files in their wheel package > >> (also, > >> >> relating to my other mail with licensing questions - they also seem > to > >> be > >> >> using PyLint). > >> >> Is this acceptable for ARIA as well, or should we manually place > these > >> >> files inside the wheel package - Or perhaps there's a different way > to > >> do > >> >> this I have not found? > >> >> > >> >> > >> >> 3) What should be the project name on PyPI (when it goes up there)? > >> Does > >> >> it have to be named "apache-ariatosca"? Can it be simply named > "aria"? > >> >> It can often get confusing when projects are named one thing on PyPI > >> and > >> >> yet the main package is named otherwise; Plus, it's simply more > >> >> straightforward to do "pip install aria" :) > >> >> I haven't seen any explicit rules about this, but I assumed it's > better > >> >> to ask. > >> > > > > My understanding is that "Apahce" should be included as part of the > > package name, and since the name of the project is AriaTosca we should > > stick to the project name so "apache-ariatosca" should work. > > wrt to cli "aria" would be much better ux, but we can also add an alias > > from "aria" to "ariatosca" for consistency. > > > > > > > >> >> > >> >> > >> >> Thanks > >> >> > >> >> > >> > > >> > > >
