According to the documentations, when deploying a project to scrapyd, I can use the git commit hash as the version, by doing this:
$ scrapyd-deploy default -p myproject --version GIT
The documentation also says that scrapyd can keep multiple versions of the same project, but will only run spiders from the latest version.
In that case, how does scrapyd determine which version is the 'latest' to use?
I hope it doesn't sort the git commit hashes lexicographically and use that order.
As stated in their docs:
Scrapyd will use the greatest version when not specified, the version must be comparable according to distutils.version.LooseVersion.
This means that using GIT as version doesn't make much sense, which is a rather big issue
Related
I want to use the Chromium source to build a stable browser version. But I do not understand how to determine stable chromium source versions because it is released several times to day, and releases have no stable or intermediate marks.
By stable version, I mean the version that is tested by some QA group and is marked as ready for production.
The daily builds that you are referring to are canary builds which are for development purposes only. If you want to check out a stable build from the Chromium repo then you need to find out the stable version.
For that you can go to https://omahaproxy.appspot.com/ and find out the current/previous stable version of Chromium/Chrome. Use channel and current_version columns as a reference.
Chromium uses tags to represent a specific version. So, for example, if the current stable version is 89.0.4389.90, execute the following git commands from your Chromium repo:
Fetch the remote tags:
git fetch --tags
List all the available tags (Optional):
git tag
Checkout the specified tag:
git checkout tags/89.0.4389.90
After checking out a specific tag, follow the commands here to pull third-party deps here
I need to use python3.7m instead of default python3.8 in my buildroot project. Is there a solution for that or only way is get older buildroot version?
You do not have to downgrade Buildroot. You can always add a custom python3 package based on an older version, e.g.: https://git.busybox.net/buildroot/tree/package/python3?id=b3424c8fc9d1199f5836483f15af48b56373609e
Here the documentation on how to add a package:
https://buildroot.org/downloads/manual/manual.html#adding-packages
One possibility is to add a custom package with a different python version, as #Ezra Bühler explained. However, that custom package must have a different name than python3, which means that you also need to make custom versions of all packages that use python3.
Therefore, a simpler possibility is to modify the Buildroot code itself. There's normally no need to go back to an older Buildroot version - instead, you can take just copy and overwrite python3 from an older version that still has python 3.7. Of course, this is a completely untested configuration so you might encounter some breakage, but it's usually doable. If you take that route, you'll want to also update python to the latest (currently python 3.7.11).
Is it possible to manage multiple versions of Perl 6 using rakudobrew?
I tried:
$ rakudobrew build moar
but this just overwrote my previous version, which was not what I intended to do. My previous version was 2017.04.3, when I now type
$ perl6 --version
This is Rakudo version 2017.07-117-g5f68c7752 built on MoarVM version 2017.07-266-ged84a632
implementing Perl 6.c.
I am looking for something similar to perlbrew install and perlbrew switch which I use to switch between different version of Perl 5.
moar is a backend. To get a specific Rakduo version, you have to specify it as well:
rakudobrew build moar 2017.07
rakudobrew build moar 2017.04.3
After doing this, you can choose which one to use:
rakudobrew switch moar-2017.04.3
If you are interested, run rakudobrew list-available to get a list of all Rakudo versions and backends that are available.
A note to most users: Unless you really have a need for the "bleeding edge" version of Rakudo, I'd recommend the relatively easier-to-install and "maintenance-free" Rakudo Star distribution. It is released about once every three months, so it's not that far behind the "bleeding edge" anyway.
I'm having some problem with my installed pods. They are not pulling the most recent (bug-fixed) version of their libraries from Github, and hence my Xcode compiler is full of warnings. I don't understand how Cocoapods works an entirely, and I'm wondering if anyone can clear it up.
How does Cocoapods know when a new version of a library is available?
What is required for Cocoapods to retreive the latest version via the
sudo pod install
comand?
How often and for what reason does a podspec need to be updated? Does it need to be updated by the author of the podspec only or by anyone?
Cocoapods are usually linked to a specific repository tag and version, so looking at AQGridView we can see two versions, version 1.2 refers specifically to the commit commit => 'f6c5589a6dabfff693fc7def7342327b9b0df3f9 whilst 1.3 differs. If the first time you ran a pod install 1.2 was the last version you would always get version 1.2 so as to not break backwards compatibility.
If you wanted to update to version you could run pod update which would check your existing podspec file and look for the latest versions ( on cocoapods! ) and use those.
If you wanted to use cocoapods but access the latest version specifically for one there is a wiki page saying how to do it here
So with that down,
When someone updates the Specs repo the pods on your computer doesn't know this instantly, you can run pod repo update to ensure you're at the latest. I expect it auto checks every so often.
Mentioned above, if you run pod update it will use the latest podspec versions
Podspecs are updated as often as people want their libraries to have a version number, ideally whenever you release a point release you should also submit a corrosponding podspec to the repo and then everyone knows they can update. It is quite often updated by volunteers, but we do get authors updating their own libraries.
pod install does not install the newest versions! Using the newest version by default is a bad idea. You should always specify the exact versions or use the pessimistic version constraint (~>).
To get notified about new versions you can use VersionEye. You can directly follow pods to receive email notifications as soon updates are available. In additional to that it can directly monitor your GitHub repository and notify you about out-dated pods in your project. That is the most convenient way. You can read more here.
if you get the notification for a new version you should first check the version number. If the pod project is using http://semver.org/ you can already on the version number see if you can update without breaking your build. In the worst case it's a major release, which very likely will break your build. In that case you have to check the change logs and the migration path. If you wanna learn about how to update right, check out the slides to continuous updating.
If you want update CocoaPods (newest) version, you can do $sudo gem install cocoapods
if you want update all library of your project, you can direct do $pod update ,or update someone library you can do $pod update [POD_NAMES ...] <<--- those command you can use anytime to update your project(if new library have been released), unless check each library by manual.
I'd very much appreciate anyone sharing best-practices, patterns, anti-patterns, backup, rollback processes that you have formulated for a pain-free, foolproof, Play framework upgrade.
I'm thinking just replacing the bin/play directory with the latest version can cause problems
Edit:
I'm looking for more specific version management strategies, say,
a) Do you just have /bin/play directory having the latest play version or
b) Do you keep versions like /bin/play-1.1 /bin/play-1.2 and change your $PATH to point to the latest (cons: you have to rebuild your modules, dependencies & libs; pros: gives better control over rollback)
I prefer to install play from source using git:
git clone git://github.com/playframework/play.git
cd play
# checkout specific version
git checkout 1.2.1
cd framework
ant
cd ..
ln -s $PWD/play ~/bin
So I have a full install including all source. Later, when play was updated to version 1.2.2 I did the following:
cd <play_home>
git pull
git checkout 1.2.2
cd framework
ant
In your application you then do
play clean && play run
The advantage of running play from a source build is that you can always and easily roll back to the previous version or even test out features from current development. This does not solve the problem of having multiple versions of play active at the same time though.
I agree with Andre. However, if you are asking for best practice for a live project, I would do it differently.
You can have multiple version installed on your local machine. The only thing you have to change is which one is visible in the path. For instance you could have 1.1, 1.2, 2.0 and depending on which one you want, you just modify your /home/youruser/.bashrc file.
The reason, why simple update of play from git or hg will not work/good idea is because, incase there are problems, you have to revert, rollback modules, or goodness know what not.
It is far better to simple swap out the play version, rebuild, test extensively, once you are ok that everything is good, then you can make the same changes in a live site.
If things don't workout, or your are hopelessly lost, all you have to do is revert the changes to your project and switch the play version. You will be back to where you started.