Sender | Message | Time |
---|---|---|
4 Dec 2020 | ||
I was actually creating new projects instead of layers, but failed to include local sources. For the base project it was easy: fury source add -s base/src . Got output:
Commited 2 tags to github. Now for the project which uses base-v1 and also adds some code I run:
but the output is that I cannot make depends-on-v2/src to include local repo. Rather it uses one specified by fury repo ... command: | 23:37:21 | |
but will try layers instead | 23:37:46 | |
* I was actually creating new projects instead of layers, but failed to include local sources. For the base project it was easy: fury source add -s base/src . Got output:
Commited 2 tags to github. Now for the project which uses base-v1 and also adds some code I run:
but the output is that I cannot make depends-on-v1/src to include local repo. Rather it uses one specified by fury repo ... command: | 23:38:46 | |
* I was actually creating new projects instead of layers, but failed to include local sources. For the base project it was easy: fury source add -s base/src . Got output:
Commited 2 tags to github. Now for the project which uses base-v1 and also adds some code I run:
but the output is that I cannot make depends-on-v1/src to include local repo. Rather it uses one specified by fury repo ... command:
Also tried | 23:39:59 | |
5 Dec 2020 | ||
Ok, so you'll need to use layers, just because they're the mechanism we're going to use for managing shading. Each layer should be "self-consistent" meaning that there should be no ambiguous conflicting projects within them, but the conflicts can occur when an import of more than one layer happens. But that makes it the correct place to be adding shading. | 09:15:15 | |
I have some problems with the concept of "local sources". They seemed a very natural concept to begin with, but having some sources which aren't in a Git repo has introduced some inconsistencies in the user interface, where things are broken at worst and confusing at best. So until I fix that (currently one of my highest priorities, after fixing the build!) I'd suggest the best thing is to manage your git repository independently of Fury, particularly as you're working with several layers. If you add that as an external repo, and avoid "local sources", it should make everything more clear. | 09:18:26 | |
The problem you are seeing with the sources using the "wrong repo" is closely related to this. The thing is, if the repo you have checked out in the same directory as the layer has the same remote as one which is defined in your layer, Fury assumes that that's what it is. The idea is that a layer may depend on two or three different repos, and if that layer is "evaluated" in a git directory, it probably means that the user wants to work on the local sources rather than the remote ones. | 09:22:09 | |
I think I just need to fix this by making things a bit more explicit in the user interface. | 09:22:23 | |
I'd recommend just keeping all the sources for all four or five projects in different directories in the same repo. There's no reason why the same commit can't be used for every layer (and hence project) that you set up. And it means that if you want to change your setup for this experiment, you have just one repo to update, and the sources for any particular commit in that repo will be self-consistent. | 09:25:58 | |
By the way, if you need me to check anything with your layer, you should always just be able to run fury layer share and send me what you've got and I should be able to take a look at it. | 09:27:14 | |
* By the way, if you need me to check anything with your layer, you should always just be able to run fury layer share and send me the hash and I should be able to take a look at it. | 09:27:24 | |
6 Dec 2020 | ||
01:56:42 | ||
[fury:issue/1591] 1 new commit
| 01:56:43 | |
[fury:issue/1595] 1 new commit
| 04:05:00 | |
7 Dec 2020 | ||
[fury:main] 1 new commit
| 18:31:38 | |
I actually got the conflicting message, although I had to change the layers a bit from what you described. Nevertheless, I think I cannot get the compile time error, as you mentioned earlier because layer conflict take precedence before actual compilation happens. | 20:16:53 | |
Yes, that's exactly what we need! 🙂 | 20:17:14 | |
* I actually got the conflicting message, although I had to change the layers a bit from what you described. Nevertheless, I think I cannot get the compile time error, as you mentioned earlier because layer conflict take precedence over actual compilation happens. | 20:17:15 | |
(at this stage, at least...) | 20:17:33 | |
* I actually got the conflicting message, although I had to change the layers a bit from what you described. Nevertheless, I think I cannot get the compile time error, as you mentioned earlier because layer conflict take precedence over actual compilation. | 20:18:03 | |
So, Fury has correctly identified (so far) that there's a conflict and it shouldn't allow the build to happen. | 20:18:08 | |
Now I imagine, I would like to make sure I understand what is the actual conflict. | 20:18:57 | |
It's currently a theoretical conflict, of course. | 20:19:20 | |
I mean, as far as Fury is concerned, there are two different versions of one of the projects... | 20:20:03 | |
I mean, I know that because I made the layers, but in the real life, user would like to see something like: layer foo is imported by those 2 layers, with specific commits. | 20:20:12 | |
It doesn't really know if it's a problematic conflict, but it's cautious... 😉 | 20:20:38 | |
Right. There are a couple of commands which can help with understanding that, but I'd like to improve them. | 20:20:56 | |
If you run fury universe projects you'll get a list of projects in all the layers. | 20:21:09 | |
ah... so even if I can run build, it would not allow me, I see | 20:21:10 | |
* ah... so even if I can run build, fury would not allow me, I see | 20:21:45 |