From sh at changeset.nyc Fri Mar 16 14:43:02 2018 From: sh at changeset.nyc (Sumana Harihareswara) Date: Fri, 16 Mar 2018 14:43:02 -0400 Subject: [Wheel-builders] Test Markdown support in READMEs Message-ID: <8802d054-92f5-5121-8b89-5491ecc46e1a@changeset.nyc> Dustin Ingram writes: https://dustingram.com/articles/2018/03/16/markdown-descriptions-on-pypi > Finally! > > I?m really excited to say that as of today, PyPI supports rendering project descriptions from Markdown! This has been a oft-requested feature and after lots of work (including the creation of PEP 566) it is now possible, without translating Markdown to rST or any other hacks! > Here are the steps necessary to make a new release with a Markdown description of your project... We'd love to get your help testing this -- please try it and comment here on wheel-builders or in https://github.com/pypa/warehouse/issues/869 if you see any problems. And there's an open issue https://github.com/pypa/wheel/issues/231 about DESCRIPTION.rst in wheels, in case any of you can weigh in there! -- Sumana Harihareswara Changeset Consulting https://changeset.nyc From sh at changeset.nyc Mon Mar 26 17:07:36 2018 From: sh at changeset.nyc (Sumana Harihareswara) Date: Mon, 26 Mar 2018 17:07:36 -0400 Subject: [Wheel-builders] new Python Package Index is now in beta at pypi.org Message-ID: <9afe6382-c41b-f7f4-709a-13efc9929f7e@changeset.nyc> The new Python Package Index at https://pypi.org is now in beta. This means the site is robust, but we anticipate needing more user testing and changes before it is "production-ready" and can fully replace https://pypi.python.org . We hope to complete the transition before the end of April 2018. We're still working to ensure the new codebase and infrastructure are reliable. So please don't rely on it (yet) unless you can handle the occasional minor outage. But we want you to try the new PyPI, test it, and tell us if you have any problems. We have IRC and Twitter livechats coming up between March 27th and April 5th to get feedback from you. More at https://pyfound.blogspot.com/2018/03/warehouse-all-new-pypi-is-now-in-beta.html . Thank you. -Sumana Harihareswara on behalf of the PyPI Team -- Sumana Harihareswara Warehouse project manager Changeset Consulting https://changeset.nyc From langdominik at protonmail.com Thu Mar 29 07:32:49 2018 From: langdominik at protonmail.com (Dominik Lang) Date: Thu, 29 Mar 2018 07:32:49 -0400 Subject: [Wheel-builders] Building Kivy for manylinux1 Message-ID: Hi all, I've opened an issue on https://github.com/pypa/wheel-builders, but that got immediately closed, so I guess that was the wrong place to ask/contribute, haha. Here's my situation: I'm not *that* experienced in the "build stuff with gcc" department, i.e. I've done it before but I don't have the in-depth knowledge. What I'm trying to do is to create a Kivy build that "just works" on as many systems as possible. Motivation: As a new guy, if the first thing you're greeted with upon installation of a framework is some obscure Cython error, then you're probably not going to bother. (Python + GUI really is a sore spot in the overall ecosystem.) I've been playing around with different systems and options for a while now (including manylinux1), though, and have started to learn how to properly build RPMs. My main question at this point is: should I even bother with manylinux1? I get that the reason for going back as far as possible is to support as many systems as possible. But RedHat 5 is on extended support only now, that means CentOS 5 also won't ever receive any fixes anymore, if I understand that right. That is, if I were to use the provided docker image, that'd be a potential security issue in itself. Also, trying to "go back in time" with newer software releases is a major effort here (relying on SDL2 and all that involves). So basically, I think I have 3 options: - Not even trying to be compatible with manylinux1. - Backport everything from the latest minor release of CentOS 6 (CentOS only supports the latest minor release). - Try to make it work on CentOS 6, first. Then try and see if I can find and fix the incompatibilities introduced by that. But that is over my head, still. Any advice would be appreciated. Cheers, Dominik -------------- next part -------------- An HTML attachment was scrubbed... URL: From msarahan at gmail.com Thu Mar 29 11:53:26 2018 From: msarahan at gmail.com (Michael Sarahan) Date: Thu, 29 Mar 2018 10:53:26 -0500 Subject: [Wheel-builders] Building Kivy for manylinux1 In-Reply-To: References: Message-ID: Take a look at https://www.python.org/dev/peps/pep-0571/ There's also conda-build, which is currently targeting CentOS 6 for the ecosystem. Full disclosure: I work for Anaconda, and I'm the maintainer of conda-build. I know that there has been some effort toward's Kivy's dependencies (SDL2 and such) on conda-forge, which is the largest community effort on conda packaging. https://conda-forge.org/ and https://github.com/conda-forge/staged-recipes/search?q=sdl2&type=Issues&utf8=%E2%9C%93 FWIW, many vendors do not fully adhere to the manylinux1 standard, so if you released noncompliant wheels, you at least would be in good company. It is better to stick to it, but it really isn't always feasible or easy. On Thu, Mar 29, 2018 at 6:32 AM, Dominik Lang via Wheel-builders < wheel-builders at python.org> wrote: > Hi all, > > > I've opened an issue on https://github.com/pypa/wheel-builders, but that > got immediately closed, > so I guess that was the wrong place to ask/contribute, haha. > > > Here's my situation: I'm not *that* experienced in the "build stuff with > gcc" department, > i.e. I've done it before but I don't have the in-depth knowledge. > > What I'm trying to do is to create a Kivy build that "just works" on as > many systems as possible. > > Motivation: As a new guy, if the first thing you're greeted with upon > installation of a framework is > some obscure Cython error, then you're probably not going to bother. > > (Python + GUI really is a sore spot in the overall ecosystem.) > > > I've been playing around with different systems and options for a while > now (including manylinux1), though, > and have started to learn how to properly build RPMs. > > > > My main question at this point is: should I even bother with manylinux1? > > > > I get that the reason for going back as far as possible is to support as > many systems as possible. > > But RedHat 5 is on extended support only now, that means CentOS 5 also > won't ever receive any fixes anymore, > if I understand that right. That is, if I were to use the provided docker > image, that'd be a potential security issue in itself. > > Also, trying to "go back in time" with newer software releases is a major > effort here (relying on SDL2 and all that involves). > > > So basically, I think I have 3 options: > > - Not even trying to be compatible with manylinux1. > > - Backport everything from the latest minor release of CentOS 6 (CentOS > only supports the latest minor release). > > - Try to make it work on CentOS 6, first. Then try and see if I can find > and fix the incompatibilities introduced by that. > > But that is over my head, still. > > > Any advice would be appreciated. > > > Cheers, > > Dominik > > > > _______________________________________________ > Wheel-builders mailing list > Wheel-builders at python.org > https://mail.python.org/mailman/listinfo/wheel-builders > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Thu Mar 29 11:57:19 2018 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 29 Mar 2018 11:57:19 -0400 Subject: [Wheel-builders] Building Kivy for manylinux1 In-Reply-To: References: Message-ID: Hi Dominik, I think the manylinx2010 image (that will be based on Centos6) should help: https://www.python.org/dev/peps/pep-0571/ https://github.com/pypa/manylinux/pull/152 Also to help create derive image, you could base yours on dockcross/manylinux-x64 (that itself derive from the manylinux one but include convenience tooling to build project) and read how you can extend it . Hth Jc On Thu, Mar 29, 2018 at 7:32 AM, Dominik Lang via Wheel-builders < wheel-builders at python.org> wrote: > Hi all, > > > I've opened an issue on https://github.com/pypa/wheel-builders, but that > got immediately closed, > so I guess that was the wrong place to ask/contribute, haha. > > > Here's my situation: I'm not *that* experienced in the "build stuff with > gcc" department, > i.e. I've done it before but I don't have the in-depth knowledge. > > What I'm trying to do is to create a Kivy build that "just works" on as > many systems as possible. > > Motivation: As a new guy, if the first thing you're greeted with upon > installation of a framework is > some obscure Cython error, then you're probably not going to bother. > > (Python + GUI really is a sore spot in the overall ecosystem.) > > > I've been playing around with different systems and options for a while > now (including manylinux1), though, > and have started to learn how to properly build RPMs. > > > > My main question at this point is: should I even bother with manylinux1? > > > > I get that the reason for going back as far as possible is to support as > many systems as possible. > > But RedHat 5 is on extended support only now, that means CentOS 5 also > won't ever receive any fixes anymore, > if I understand that right. That is, if I were to use the provided docker > image, that'd be a potential security issue in itself. > > Also, trying to "go back in time" with newer software releases is a major > effort here (relying on SDL2 and all that involves). > > > So basically, I think I have 3 options: > > - Not even trying to be compatible with manylinux1. > > - Backport everything from the latest minor release of CentOS 6 (CentOS > only supports the latest minor release). > > - Try to make it work on CentOS 6, first. Then try and see if I can find > and fix the incompatibilities introduced by that. > > But that is over my head, still. > > > Any advice would be appreciated. > > > Cheers, > > Dominik > > > > _______________________________________________ > Wheel-builders mailing list > Wheel-builders at python.org > https://mail.python.org/mailman/listinfo/wheel-builders > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From langdominik at protonmail.com Thu Mar 29 17:29:21 2018 From: langdominik at protonmail.com (Dominik Lang) Date: Thu, 29 Mar 2018 17:29:21 -0400 Subject: [Wheel-builders] Building Kivy for manylinux1 In-Reply-To: References: Message-ID: Thanks, that already helped a lot. I did not know about that PEP. So CentOS 6 it is for sure. I'll have a look at all of these in time, I'd say, and maybe even expand on that dockcross image. One question regarding conda: How are the OS dependencies handled? I've looked through the scripts and might've missed it. AFAIU so far, SDL2 determines the dependencies both at build- and at runtime. Which makes it relatively easy to get a build, but if they're not there initally, they won't be available later. Thanks again, Dominik ??????? Original Message ??????? On 29 March 2018 5:53 PM, Michael Sarahan wrote: > Take a look at https://www.python.org/dev/peps/pep-0571/ > > There's also conda-build, which is currently targeting CentOS 6 for the ecosystem.? Full disclosure: I work for Anaconda, and I'm the maintainer of conda-build.? I know that there has been some effort toward's Kivy's dependencies (SDL2 and such) on conda-forge, which is the largest community effort on conda packaging.? https://conda-forge.org/ and https://github.com/conda-forge/staged-recipes/search?q=sdl2&type=Issues&utf8=%E2%9C%93 > > FWIW, many vendors do not fully adhere to the manylinux1 standard, so if you released noncompliant wheels, you at least would be in good company.? It is better to stick to it, but it really isn't always feasible or easy. ??????? Original Message ??????? On 29 March 2018 5:57 PM, Jean-Christophe Fillion-Robin wrote: > Hi Dominik, > > I think the manylinx2010 image (that will be based on Centos6) should help: > > https://www.python.org/dev/peps/pep-0571/ > > https://github.com/pypa/manylinux/pull/152 > > Also to help create derive image, you could base yours on dockcross/manylinux-x64 (that itself derive from the manylinux one but include convenience tooling to build project) > > and read how you can extend it. > > Hth > > Jc From msarahan at gmail.com Thu Mar 29 21:47:36 2018 From: msarahan at gmail.com (Michael Sarahan) Date: Thu, 29 Mar 2018 20:47:36 -0500 Subject: [Wheel-builders] Building Kivy for manylinux1 In-Reply-To: References: Message-ID: Conda's approach to system level dependencies can be summarized by "package all the things." Essentially everything is available or could be available as a package. There are some fringe exceptions, like glibc (tied too strongly to kernel) and X11 (again, tied to hardware optimization tightly). Otherwise, essentially everything can be (and many things are) available as conda packages. For system-level packages, the packages have traditionally contained both shared objects and any headers required. As a result, you'll often see the same package dependency listed as a build-time and a run-time dependency. Conda-build has a pretty new feature called "run_exports" where a system-level package can declare runtime dependencies that it should "export" to other packages that use the system level package at build time. There's a better description at https://conda.io/docs/user-guide/tasks/build-packages/define-metadata.html#export-runtime-requirements Conda-forge is a little behind on taking advantage of all the new conda-build features. What I would expect to see in a kivy conda recipe would be something like: requirements: build: - sdl2_package_name run: - sdl2_package_name My best thought for comparison with wheels is that a large collection of conda packages is more work to get started (building the system-level dependencies as packages, vs. just using existing system level libraries from apt or yum and statically linking against them), but once a good collection of conda packages is established, the dependency solver makes it easier than wheels to keep track of package compatibility needs and boundaries. Conda-forge especially has so many useful low-level libraries that it is a compelling platform. On Thu, Mar 29, 2018 at 4:29 PM, Dominik Lang wrote: > Thanks, that already helped a lot. I did not know about that PEP. > So CentOS 6 it is for sure. > > I'll have a look at all of these in time, I'd say, and maybe even expand on > that dockcross image. > > One question regarding conda: How are the OS dependencies handled? > > I've looked through the scripts and might've missed it. AFAIU so far, > SDL2 determines the dependencies both at build- and at runtime. Which > makes it relatively easy to get a build, but if they're not there > initally, they won't be available later. > > Thanks again, > > Dominik > > > ??????? Original Message ??????? > > On 29 March 2018 5:53 PM, Michael Sarahan wrote: > > > Take a look at https://www.python.org/dev/peps/pep-0571/ > > > > There's also conda-build, which is currently targeting CentOS 6 for the > ecosystem. Full disclosure: I work for Anaconda, and I'm the maintainer of > conda-build. I know that there has been some effort toward's Kivy's > dependencies (SDL2 and such) on conda-forge, which is the largest community > effort on conda packaging. https://conda-forge.org/ and > https://github.com/conda-forge/staged-recipes/search?q= > sdl2&type=Issues&utf8=%E2%9C%93 > > > > FWIW, many vendors do not fully adhere to the manylinux1 standard, so if > you released noncompliant wheels, you at least would be in good company. > It is better to stick to it, but it really isn't always feasible or easy. > > > ??????? Original Message ??????? > > On 29 March 2018 5:57 PM, Jean-Christophe Fillion-Robin < > jchris.fillionr at kitware.com> wrote: > > > Hi Dominik, > > > > I think the manylinx2010 image (that will be based on Centos6) should > help: > > > > https://www.python.org/dev/peps/pep-0571/ > > > > https://github.com/pypa/manylinux/pull/152 > > > > Also to help create derive image, you could base yours on > dockcross/manylinux-x64 (that itself derive from the manylinux one but > include convenience tooling to build project) > > > > and read how you can extend it. > > > > Hth > > > > Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msarahan at gmail.com Thu Mar 29 22:12:02 2018 From: msarahan at gmail.com (Michael Sarahan) Date: Thu, 29 Mar 2018 21:12:02 -0500 Subject: [Wheel-builders] Building Kivy for manylinux1 In-Reply-To: References: Message-ID: PS: I think it's worth mentioning that the main complaint I hear about conda packages is that you need conda to install them, whereas with wheels, you just install wherever wheels are installable (essentially everywhere, including anaconda/miniconda installations). That's compelling, especially for the core project maintainers who have way more interesting things to do than worry about packaging. I still think the dependency solver in conda helps prevent broken installations, but I can't argue that wheels make less work for maintainers. The best answer for your packaging might be both wheels and conda packages. Conda-build can use pip to build wheels and conda-packages in one go, so if that's a route you're interested in, feel free to contact me off-list, or on the conda-build issue tracker. It's still pretty primitive, but it is workable. On Thu, Mar 29, 2018 at 8:47 PM, Michael Sarahan wrote: > Conda's approach to system level dependencies can be summarized by > "package all the things." Essentially everything is available or could be > available as a package. There are some fringe exceptions, like glibc (tied > too strongly to kernel) and X11 (again, tied to hardware optimization > tightly). Otherwise, essentially everything can be (and many things are) > available as conda packages. For system-level packages, the packages have > traditionally contained both shared objects and any headers required. As a > result, you'll often see the same package dependency listed as a build-time > and a run-time dependency. Conda-build has a pretty new feature called > "run_exports" where a system-level package can declare runtime dependencies > that it should "export" to other packages that use the system level package > at build time. There's a better description at > https://conda.io/docs/user-guide/tasks/build-packages/ > define-metadata.html#export-runtime-requirements > > Conda-forge is a little behind on taking advantage of all the new > conda-build features. What I would expect to see in a kivy conda recipe > would be something like: > > requirements: > build: > - sdl2_package_name > run: > - sdl2_package_name > > My best thought for comparison with wheels is that a large collection of > conda packages is more work to get started (building the system-level > dependencies as packages, vs. just using existing system level libraries > from apt or yum and statically linking against them), but once a good > collection of conda packages is established, the dependency solver makes it > easier than wheels to keep track of package compatibility needs and > boundaries. Conda-forge especially has so many useful low-level libraries > that it is a compelling platform. > > On Thu, Mar 29, 2018 at 4:29 PM, Dominik Lang > wrote: > >> Thanks, that already helped a lot. I did not know about that PEP. >> So CentOS 6 it is for sure. >> >> I'll have a look at all of these in time, I'd say, and maybe even expand >> on >> that dockcross image. >> >> One question regarding conda: How are the OS dependencies handled? >> >> I've looked through the scripts and might've missed it. AFAIU so far, >> SDL2 determines the dependencies both at build- and at runtime. Which >> makes it relatively easy to get a build, but if they're not there >> initally, they won't be available later. >> >> Thanks again, >> >> Dominik >> >> >> ??????? Original Message ??????? >> >> On 29 March 2018 5:53 PM, Michael Sarahan wrote: >> >> > Take a look at https://www.python.org/dev/peps/pep-0571/ >> > >> > There's also conda-build, which is currently targeting CentOS 6 for the >> ecosystem. Full disclosure: I work for Anaconda, and I'm the maintainer of >> conda-build. I know that there has been some effort toward's Kivy's >> dependencies (SDL2 and such) on conda-forge, which is the largest community >> effort on conda packaging. https://conda-forge.org/ and >> https://github.com/conda-forge/staged-recipes/search?q=sdl2& >> type=Issues&utf8=%E2%9C%93 >> > >> > FWIW, many vendors do not fully adhere to the manylinux1 standard, so >> if you released noncompliant wheels, you at least would be in good >> company. It is better to stick to it, but it really isn't always feasible >> or easy. >> >> >> ??????? Original Message ??????? >> >> On 29 March 2018 5:57 PM, Jean-Christophe Fillion-Robin < >> jchris.fillionr at kitware.com> wrote: >> >> > Hi Dominik, >> > >> > I think the manylinx2010 image (that will be based on Centos6) should >> help: >> > >> > https://www.python.org/dev/peps/pep-0571/ >> > >> > https://github.com/pypa/manylinux/pull/152 >> > >> > Also to help create derive image, you could base yours on >> dockcross/manylinux-x64 (that itself derive from the manylinux one but >> include convenience tooling to build project) >> > >> > and read how you can extend it. >> > >> > Hth >> > >> > Jc >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: