I'd like to use the latest development version of clojure.data.xml. I'm using Leiningen to manage dependencies. However, there is no SNAPSHOT version in the repository on Central. How can I easily load the latest version from GitHub?
The Maven Central repository does not hold snapshots. To use snapshots of the Clojure projects, you need to add the snapshot repository to your project. Full details here: http://dev.clojure.org/display/community/Maven+Settings+and+Repositories
The key line to add to a Leiningen project is:
:repositories {"sonatype-oss-public" "https://oss.sonatype.org/content/groups/public/"}
The latest snapshot dependency version for data.xml is:
[org.clojure/data.xml "0.2.0-SNAPSHOT"]
All Clojure contrib projects are built and released as a snapshot on every commit (gathered in 1 hr polls) AND once a week regardless of commits. So, pulling a snapshot will generally be the same or nearly the same as what's on github.
One way to get the latest version from GitHub would be to press the green button at https://github.com/clojure/data.xml and then the 'copy to clipboard' button that will appear next. Then get a terminal on your machine and go git clone <pasted here>. You will now have that repository locally.
From there if you wanted to use that development version from another lein project you could type lein install from the command line. If that still didn't give you a great workflow please read http://jakemccrary.com/blog/2012/03/28/working-on-multiple-clojure-projects-at-once/.
Related
Currently we are using Nugget packages as our Azure artifacts and during the release process we download the artifact using "Download Package" task . It is working perfectly. But we noticed that even though we have downloaded the package already,during the next run of the pipeline in the same agent, again we have to download it. This is taking lot of time. So we want to prevent the package from getting download if it already present. Could you provide a way to reuse the already downloaded package.
In release pipeline, the System.DefaultWorkingDirectory (Example: C:\agent\_work\r1\a. Same as Agent.ReleaseDirectory and System.ArtifactsDirectory) is the directory to which artifacts are downloaded during deployment of a release. The directory is cleared before every deployment if it requires artifacts to be downloaded to the agent. This is a default behavior, we can not change it unfortunately.
I've noticed that after the packages required written in "requirements.txt" were installed they are not installed anymore every time I push changes into the Heroku application I'm working, so I was assuming that those files were not modified anymore.
I then changed a file in /app/.heroku/python/lib/python2.7/site-packages/target_library/target_file but when I do git push the file goes back to its original state, although the library is not being installed again.
Is there a way to avoid libraries to be reseted or any workaround?
Based on the last answer.
or fork the library on GitHub and install the forked version.
Here are the few steps I've tested and it worked for me:
1- Fork the package repo on GitHub.
2- Edit it and change whatever you need.
3- Now remove the original package name from your requirments.txt and replace it with git+https://github.com/you-github-username/forked-edited-package.git
Now it should simply install the edited package to your Heroku dyno when you deploy the project
No this can't possibly work. Heroku will always install the packages directly from PyPI and won't know anything about your modifications. I don't know why you say they aren't installed again - on the contrary, they are.
Are you sure you really need to do this? It's a fairly unusual thing to do. If you are sure you do, then the only thing to do is to either for the files into your own project, or fork the library on GitHub and install the forked version.
What I'm looking for is something that builds C++ code every night or on every commit, and then, crucially, runs some commands to create a zip or a package which can then be added to a "Release" on GitHub.
I know there's travis-CI, which automatically compiles commits, and it can run for example a CMake INSTALL target and then CPack, which would create a zip or installer package. But it's not possible to upload these files to GitHub or display them somewhere.
I was thinking that maybe there was another service for that available which integrates with GitHub, but couldn't find any Google hits whatsoever. Preferably this would be separate from travis-CI, since on travis you would run debug-like builds (static analysers etc.). While for a release you want to deploy, you'd put release flags, build documentation, etc.
This is for an open source project so I'm looking for something that does this free for open source projects, preferably without setting up own server infrastructure.
There are a few related posts like Travis-CI Auto-Tag Build for GitHub Release or a travis section on deployment but they haven't really answered my question.
You can use travis-CI for this, check out "build artifacts" in the documentation.
https://docs.travis-ci.com/user/deployment/releases/
At time of writing it looks like this:
GitHub Releases Uploading
Travis CI can automatically upload assets from your $TRAVIS_BUILD_DIR to your git tags on your GitHub repository.
Please note that deploying GitHub Releases works only for tags, not for branches.
For a minimal configuration, add the following to your .travis.yml:
deploy:
provider: releases
api_key: "GITHUB OAUTH TOKEN"
file: "FILE TO UPLOAD"
skip_cleanup: true
on:
tags: true
Basically you would have to tag each commit that you want to get uploaded, so you could make a cron job that does that regularly, or do it manually, only on days that interesting work happened.
Alternatively, you could make it upload all builds to a google cloud storage account, or an amazon s3 account, and then you can cron job it from there. See docs for instance here.
I'm developing a Leiningen plugin. Actually, I'm working on a patch to an existing Leiningen plugin. I've made some changes, and now I want to see if they work.
What do I do?
I made these changes to support another project I'm working on. I'd like to point that project at my local working copy of the plugin to test my changes, but I don't see a way to do that.
Leiningen offers checkout dependencies, which solve this problem for dependencies, but not for plugins. Is there an equivalent for plugins?
Publish your forked version with a different group-id, either to clojars or to your local repo (with lein install). Then, in the project that uses the plugin, depend on your new artifact-id instead of the public one.
I've been contributing to a project in which there's a fixed pom.xml, but I tend to modify project.clj, temporarily, for various purposes. Most of the time, Leiningen seems to ignore pom.xml, but lein install and lein deploy rewrite pom.xml. Is this necessary to Leiningen's functioning? If not, can I stop it? Haven't found anything about this in the online docs yet.
It's not a big problem, but I'd rather not deal with having to restore the official pom.xml in my project before doing a 'git commit', for example.
EDIT: I discovered a solution for my situation, which is to create a 'checkouts' directory with a link to the other project. This causes the other project to be pulled in, without creating a new jar. However, I'm still curious: Does Leiningen need to create pom.xml e.g. for lein install? Why? I'd like to understand the process.
I'm unsure of whether lein install can be run without generating a pom.xml.
The reason it generates a pom is that leiningen uses maven to grab all the dependencies. In fact, maven is able to get dependencies from clojars and leiningen uses it for the clojure dependencies as well as the java ones. Maven requires a pom.xml to specify repository locations and other configuration necessary to run javac (or any other build commands) in addition to a groupId and artifactId to deploy your library to a (potentially local) repository
Another possible workaround to your issue is to use changelists (specifically, if using tortoiseSVN, I'd use the ignore-on-commit changelist) to ignore your pom.xml in most situations commitwise. I believe this stackoverflow answer may assist you with how to do that in git.