Hi lance,
Another best practice I should have mentioned: if you are using your
TOOL_DEV_LOCAL_DIR as a source code repository for developing your tools
(where you are committing tool development change sets into your hg repository
in TOOL_DEV_LOCAL_DIR), you should not push the change log
I'm actually still a bit confused as to what the expected workflow is.
Should I be able to clone the tool shed repo to my local development
workstation (TOOL_DEV_LOCAL_DIR), commit a change, and then push that
change back to the Tool Shed?
I've added some comments inline to clarify.
Greg
Hi Lance,
On Sep 27, 2012, at 4:37 PM, Lance Parsons wrote:
I'm actually still a bit confused as to what the expected workflow is.
Should I be able to clone the tool shed repo to my local development
workstation (TOOL_DEV_LOCAL_DIR), commit a change, and then push that change
back to the
I'm sorry I wasn't more clear. I do believe that those links explain
the behavior I am seeing. However, let me try to describe it a different
way. It seems that there will, at most, be one installable revision of
a given version of a tool. Here I use revision to denote a mercurial
revision
Hi Lance,
I need to figure out precisely what steps you are taking to produce this
behavior, as I have not been able to do so. Please see my inline comments, and
let me know more information about each step you are taking to produce this
behavior.
On Sep 25, 2012, at 10:24 AM, Lance Parsons
Hi Lance,
On Sep 21, 2012, at 6:04 PM, Lance Parsons wrote:
OK, I was able to get a new version installed. It seems there are two issues:
1) New revisions with the same version ionvalidate previous revisions.
This means that Galaxy servers with the old, and now invalid, revisions are
I've run into this issue again, and I'm having a hard time working
around it. However, I have confirmed that at least some updates to a
tool in the tool shed will invalidate previously valid revisions and
thus prevent users from installing or updating the tool at all.
For example, push
OK, I was able to get a new version installed. It seems there are two
issues:
1) New revisions with the same version ionvalidate previous
revisions. This means that Galaxy servers with the old, and now
invalid, revisions are not able to update the tool (nor install it again).
2) Pushes
Hello Lance,
I've just committed a fix for getting updates to installed tool shed
repositories in change set 7713:23107188eab8, which is currently available only
in the Galaxy central repository. However, my fix will probably not correct
the issue you're describing, and I'm still not able to
Actually, I think that is exactly the issue. I DO have 3:f7a5b54a8d4f
installed. I've run into a related issue before, but didn't fully
understand it.
I believe what happened was:
1) I pushed revision 3:f7a5b54a8d4f to the tool shed which contained the
first revision of version 0.2 of the
I've updated my development system now, and when I try to get updates
for that particular tool (htseq_count) I run into the following error.
Any ideas on how I can/should fix this? Thanks.
URL:
Hi Lance,
What is the changeset revision that you installed? It looks like you could
only have installed one of the following 3 revisions:
1:14e18dc9ed13
2:f5d08224af89
4:14bec14f4290
Since you could not have installed 3:f7a5b54a8d4f, I'm not quite sure how you
could be trying to update to
Thanks Greg. I used you're updated version and added numpy as a separate
dependency. It seems to work in my development system. I haven't
updated my qa or production versions yet, so I can't check there.
Perhaps you could test it and let me know if there are issues, etc.
Glad I can be of
Hello Lance,
See my inline comments.
On Sep 4, 2012, at 3:15 PM, Lance Parsons wrote:
I've put together a tool wrapper for the htseq-count script that is part of
the HTSeq python package and uploaded that to the tool shed. However, I have
discovered that the tool dependancies do not
I've put together a tool wrapper for the htseq-count script that is part
of the HTSeq python package and uploaded that to the tool shed.
However, I have discovered that the tool dependancies do not install
properly. There are a couple of issues that I've run into.
1) The biggest issue is
Hi Lance,
Thanks for reporting these issues - the tool dependencies component is fairly
new, so you may have uncovered some problems that need correction. I'll take a
look at these. make corrections if necessary, and get back to you when all is
functional.
Thanks!
Greg Von Kuster
On Sep 4,
16 matches
Mail list logo
