I would like to be notified every time a new version of Virtualenv is released on PyPI, preferably by email or by RSS feed. Is this possible?
Yes, it's possible.
libraries.io
The open(*) libraries.io service provides an e-mail notification service and RSS release feeds for Python package releases.
An RSS feed URL follows these pattern:
https://libraries.io/pypi/{PACKAGENAME}/versions.atom
Example:
curl -L https://libraries.io/pypi/virtualenv/versions.atom
For the email subscription you need to login via github/gitlab/bitbucket OAuth, but it just requests the email address over OAuth. After login you can browse to
https://libraries.io/pypi/{PACKAGENAME}
and hit the subscribe button to add a package to your subscriptions.
*open as in the server software being open source and the aggregated data being available under a creative commons license.
As of 2018-08, the libraries.io notifications aren't really reliable. For example, the PyPI release history page of a project has a new release and libraries.io doesn't send a notification mail nor updates the RSS feed for 11 days (and counting).
Anitya
Anitya (a.k.a. release-monitoring.org) is another open project for release notification. It originates from the Fedora context and Fedora infrastructure uses it, but it's basically open for anyone to create some email release notifications. Besides PyPI it supports monitoring other release sources.
A small howto:
sign-up/sign-in to release-monitoring.org
check if the PyPI packages you are interested in are already available, otherwise register the missing ones ('add project')
sign-up/sign-in to Fedora Notfications, create a new filter in the email section and add the 'Anything regarding a particular "upstream project"' rule from the Anitya rules listing. There you can specify a comma separated list of project names.
This service is supposed to check for new releases twice a day.
PyPI vs. pyup.io
As of 2018, pypi.org directly doesn't provide similar functionality. It just provides a release feed for all releases. But it links to libraries.io from each package page (for statistics). Pypi also links to similar notification services in the GitHub ecosystem.
For example, pyup.io implements notifications by connecting to one or many of your GitHub repositories - requiring a bunch of broad OAuth GitHub write permissions. It then periodically scans the repository's requirements file and is able to create pull requests if newer dependency versions are available.
Yes, an RSS feed is available from pypi.org, see: https://pypi.org/rss/project/virtualenv/releases.xml
PyPI Notifier watches your projects' requirements.txt files and emails you when a required package is updated.
http://www.pypi-notifier.org
You connect with your GitHub account and select your repos.
If you are interested in this to keep your installation up to date, you can use pip (as suggested on Super User):
$ pip list --outdated
pyflakes (1.2.3) - Latest: 1.3.0 [wheel]
The Warehouse project that powers the
The Python Package Index (PyPI) at PyPI.org had a pull request to add support for "package update feeds" at URLs of the form /rss/{package_name}/updates.xml. That has been closed and in favour of a more general issue for a different, yet-to-be-implemented API.
When/if that goes live, that API will become the most direct and official way to get the updates you're after.
I searched for a solution and https://newreleases.io seems to be perfect and up to date. I could not get email notifications working with libraries.io.
There's now a package called yolk that will check PyPi for updates on your installed packages.
pip install yolk
yolk -l # List all of the installed packages yolk can check
yolk -U # Check PyPi for updates on the installed packages
It doesn't seem to work for Python 3 yet, although there is a Python 3 fork yolk3k. You can schedule this to go once a day and notify you in case there's a new version...
Related
We have a React App which uses some components written by us and published to our internal npm repository. Our code is maintained in Bitbucket Data Center, the build is done with Bamboo and the npm repository is hosted in JFrog Artifactory. We work with feature branches and pull requests for developing new features.
It happens often that a new feature in the app, requires a change in the component. In this case, each repository (the App and the component) will have its own feature branch and pull request. Many times the component interface changes, so that the App needs the pull request version of the component and not the mainline one to build and to be tested.
The build is done exclusively by the build server, so that the bundled javascript files are not committed to git.
Let's say the component has version 1.0.0. A new feature in the App needs a change in the component. In this case, the component version will incremented to 1.0.1. We don't want to publish it to Artifactory, until version 1.0.1 is tested, but at the same time, the build of the new App version needs the changes from version 1.0.1.
Our current solution is to change the package version of the component during the build of feature branches to something like 0.<Ticket #>.<Build #>. This 0.x.x version will be published to Artifactory so that the App feature branch can use it to compile.
We use 0.x.x so that the version is never bigger than the current released version. Once the component is merged to the main branch, it will compile with the right version (1.0.1) and will be published to Artifactory again.
I find this solution cumbersome, it requires some funny build scripts, making sure that the branch name always follows some convention and teaching developers about it.
I wonder if there is a better way for managing pull requests and feature branches using npm, without having to manipulate the package.json during build time, depending if it is a feature branch or the main branch.
Sounds like you are using artifactory like a secondary version / staging for the npm package, just use npm?
I am not in devops, but have worked on a few packages, testing a package that has not been released does not sound like testing the package - what about using a beta tag npm publish --tag beta, pulling that into your app npm i package#beta then testing your application in a staging environment?
As i expect you know if you apply a tag then the tag would need to be specified to be pulled into a repo so you can use it to deter users from using that version of the package - an i believe you can delete versions later if you are dead set on not having it public.
Here is a medium article which may be helpful?
I have a private npm package that is currently published to npm. The maintainer before me did not consider automated versioning, and the version is 1.0.58.
I have installed semantic-release and a small GitHub app that can be found here: https://github.com/zeke/semantic-pull-requests
My Github Action is setup properly, because when I push to main, the process goes through and reach the publishing step. However, the tags that are created started at 1.0.0, then 1.0.1, etc.
I tried creating a tag manually on the main branch at the latest merge, that tag is v1.0.58, but when I publish again, the tag that is created is still 1.0.2, etc. As such, I get an error message that says I can't publish "over" the current version.
How do I go the 1.0.59 with a fix:... commit?
Thanks everyone!
Forgot to post solution...
It seems Semantic Pull Requests did not have a proper starting point as the initial tag was created after it was linked to the repository. Uninstalling Semantic Pull Requests, adding the latest tag (corresponding to current version of published npm package) manually and reinstalling Semantic Pull Requests caused to process to go through flawlessly with semantic-release.
What are the differences between aspnetcidev and aspnetvnext?
I see that aspnetcidev says "quick builds", but what does this mean?
Jan 29, 2016 edit:
This information is now part of the ASP.NET wiki: https://github.com/aspnet/Home/wiki/NuGet-feeds
The ASP.NET build system uses 3 myget feeds for each branch + nuget.org.
aspnetvolatile<branch> (aspnetvolatiledev/aspnetvolatilerelease)
aspnetci<branch> (aspnetcidev/aspnetcirelease)
aspnetvnext (dev branch)/aspnetrelease (release branch)
After each repo under github.com/aspnet builds successfully, each package produced by it is pushed to the corresponding volatile feed.
After the graph of repos is build, we trigger the Coherence build. This build verifies that the packages have matching versions and their references are correct (that they are coherent). Then, it pushes them to aspnetci<branch>.
Once the Coherence build passes, we run all our tests on the packages in the aspnetci<branch> feed. If the tests pass, we sign the packages and ship them to aspnetvnext or aspnetrelease
So the differences are:
aspnetvolatile<branch>
latest packages
possible not coherent
not tested
not signed
updated on every checkin
mostly used to diagnose build failure
aspnetci<branch>
possible not latest
coherent
not tested
not signed
updated when all repos build successfully
used by our build system
aspnetvnext/ (aspnetrelease|nuget.org)
possible not latest
coherent
signed
tested
updated when everything works
used for stable packages
Once the aspnetcirelease feed is stable, we push the packages from it to nuget.org.
Unless you work on developing new features for ASP.NET, I recommend that you use aspnetvnext (for dev bits) or nuget.org (for release bits). The release feed (aspnetrelease) is just a staging feed and it's not always in a good shape.
Edit:
I think it's easier to understand from a table:
I'm abrade that you can get the exact answer on the question only from Microsoft. You can open https://www.myget.org/gallery and filter for "aspnet" for example and will find many other repositories published for different teams.
For me more interesting is the information displayed by .NET Version Manager: dnvm (without parameters):
Thus, for me, the source https://www.myget.org/F/aspnetvnext/api/v2/ (or https://www.myget.org/F/aspnetvnext/api/v3/index.json) is the "official" place for the night builds of ASP.NET 5.
On the other side by filtering of https://www.myget.org/gallery "aspnet" you can see that aspnetvnext contains more distinct packages as aspnetcidev.
It's clear that both repositories probably contains different set of packages.
One important example where the repository https://www.myget.org/gallery/aspnetcidev be used is the new .NET Command Line Interface (.NET CLI) which you find on GitHub here. The new dotnet utility uses https://www.myget.org/F/aspnetcidev/api/v3/index.json together with many other sources in https://github.com/dotnet/cli/blob/master/NuGet.Config.
I suppose that AspNetCIDev is the repository of packages required for .NET CLI. It's the utility, which should replace dnx and dnu in RC2 of ASP.NET 5. See the post, this one and some other.
My standard route has been to go to confluence, find the docs sections, then navigate through to the install docs for the version, e.g. sakai 10:
https://confluence.sakaiproject.org/x/iYGLBQ
Through one means or another I happened across the source route to this too, so starting here....
http://source.sakaiproject.org/release/
You get redirected to the latest stuff, and appended version numbers to that url gives you other docs, e.g. adding 2.8.2 or 10 to the end of the url
But the links to what I should download are quite often not there, at the time of writing the 10 tar ball and zip in the confluence links are dead and the source.sakaiproject links doesn't have the 10 docs yet (redirects to 2.9.3) presumably this is because v10 is not released yet....
So, I'd like to evaluate a new version of a sakai source install, what's the best way to do this? (considering the official documentation for install is still being formed)
Do I download the latest SVN, or the latest RC or the latest beta or??? How do I know what's best to test against without being "too" bleeding edge? Is there a recommended tar ball/zip link to test against? Is there a "latest good" SVN branch?
The latest code is always in the Sakai trunk (currently svn):
https://source.sakaiproject.org/svn/sakai/trunk/
That code may very well not be stable though as it is where things are being actively developed. If you are not actively developing then you should stick to the releases as indicated on the project website here:
http://sakaiproject.org/current-release
If you want to use something in between (say an upcoming release) then you can grab the most recent tag or maybe use a recent branch (both currently in svn, latest shown below at the time I write this):
https://source.sakaiproject.org/svn/sakai/branches/sakai-10.x/
https://source.sakaiproject.org/svn/sakai/tags/sakai-10-rc02/
The reality of the situation is that if you want to use something other than the release then you should really participate in the dev community for Sakai. Joining the mailing lists and the weekly calls will provide the information you are asking about and much more.
Recently, I've wanted to deploy OpenERP and also, recently, I learned about Heroku.
I thought about how to deploy OpenERP on Heroku and it came to me that there's no python package for OpenERP.
So I thought about learning how to create python packages and then package up OpenERP for my personal use on GitHub or Launchpad (because OpenERP uses Launchpad and bazaar) and then, if it is useful, submit it to PyPI.
But, first, I'll check with the rest of the world. here for some advice.
Would you recommend me to take this route?
Would it be beneficial to the OpenERP community?
Would it be a wise method of deployment, through a python package?
What are the reasons that the official python packages on PyPI have been abandoned?
OpenERP already has packages and bundles for different O/Ses available. I would advise against creating one specifically for PyPI.
If you create one, please, please commit to maintaining it. If you don't, it too will be abandoned.