It seems there is a breaking change to the name of the bower package (https://github.com/Breeze/breeze.js.labs/commit/193e79443918c3836699aa06a0545e101f44d54d).
It looks like the name of the bower package was changed from breeze.js.labs to breeze-client-labs. I didn't see anything documented in any of the recent release notes.
This is causing my build to fail since the bower.json file still references breeze.js.labs and not breeze-client-labs.
I would expect the old package to remain to prevent from breaking peoples builds.
Thanks
You're catching us in release transition. Haven't prepared release notes yet. Just days away.
However, the breeze.js.labs github repo never served a bower package before. There was a "breeze.js.labs" bower package served out of a different github repo. It hadn't been updated in months and frankly I don't know what it held. It was not official. It was not ours. We had no responsibility for it. I asked the owner to give it up and he did (for which we are grateful).
I also note that "breeze labs" warns you that it is never to be regarded as stable or permanent. That's not a license to break you for the fun of it but it it gives us more leeway than we have in breeze core.
The net of it is that I'm sorry for the inconvenience .. and that's as far as that goes.
Moving forward, there are 2 packages to consider: breeze-client and breeze-client-labs. Please adjust accordingly.
Related
The last time I deployed the project, the build worked perfectly.
In the meantime I have changed nothing that would affect the pip requirements, yet I get an error when building:
Could not find a version that matches Django<1.10,<1.10.999,<1.11,
<1.12,<1.9.999,<2,<2.0,==1.9.13,>1.3,>=1.11,>=1.3,>=1.4,>=1.4.10,
>=1.4.2,>=1.5,>=1.6,>=1.7,>=1.8
I get the same error when building the project locally with docker-compose build web.
What could be the problem?
The problem here is that although you may not have modified any requirements, the dependencies of a project can sometimes change on their own.
You may even have pinned all of your own requirements (which is generally a good idea) but that still won't help if one of them itself has an unpinned dependency.
Anywhere an unpinned dependency exists, you can run into this.
Here's an example. Suppose your requirements.in contains super-django==1.2.4. That's better than simply specifying super-django, as you won't be taken by surprised if a new, incompatible version of the Super Django package is released.
But suppose that in turn Super Django 1.2.4, in its requirements, lists:
Django==1.11
django-super-admin
If a new version of Django Super Admin is released, that requires say Django>=2.0, your next build will fail because of the mutually exclusive requirements.
To track down the culprit when you run into such a failure, you need to examine the build logs. You'll see there something like:
Could not find a version that matches Django==1.11,>=2.0 [etc].
So now you know to look back through the logs to find what is wanting to install Django>=2.0, and you'll find:
adding Django>=2.0
from django-super-admin==1.7.0
So now you know that it's django-super-admin==1.7.0 that is the key. Since you can't trust super-django to pin the correct version of django-super-admin, you'll have to do it yourself, by adding django-super-admin<1.7.0 to the requirements.in of your project.
There's more information about this at How to identify and resolve a dependency conflict.
You can also Pin all of your project’s Python dependencies to ensure this never happens again with any other dependency, though you sacrifice some flexibility for the guarantee.
Note: I am a member of the Divio team. This question is one that we see quite regularly via our support channels.
I've finally upgraded an old project from a folder of downloaded js-libs, which were committed to the repository, to bower. It works great, using a new library is great, upgrades are much easier, but - what if a package is broken?
In this specific case, there is a small bug in the library, which affects me hugely. A solution has been submitted via PR 2 months ago, but hasn't been merged yet. And even if it gets merged, it doesn't mean a new version will be published right after.
What is the best way to apply the fix myself, in a way, that I could switch back to the official package, whenever a new and fixed version has been published.
I see two options:
download the code (as I used to have it) and modify it locally + commit it into the repo
fork the original project, merge the change into the project and publish it as a new (temporary) bower package
1st solution seems stupid and 2nd a bit too complicated just to change one line of code. In either case I'd need to keep my eyes opened if something has changed and switch back and forth manually.
Are those the only two options, or am I missing something?
I just started using TFS last week in a new job. My previous experience has primarily been with Subversion and one thing I liked about Subversion is that it forces you to get latest before checking in anything that would be conflicting. Furthermore, you have to resolve conflicts (or explicitly mark them as resolved even if they aren't really).
In TFS it seems like people are inadvertently wiping out other people's changes from time to time when 2 people have worked on the same file. I'm sure this is certainly due to inexperience with TFS, but it seems like the workflow of Subversion made it harder to do this and while I regularly had to help people resolve conflicts in Subversion, I don't remember having any real issues with people wiping out other people's code accidentally.
Is there a way to make TFS force you to get latest AND resolve all conflicts before checking in?
This could depend on a few things but most relevant could be the workspace setup (local or server). For example, the server workspace provides you the option to enforce the get latest. Other differences could include the types of locks available under each workspace type.
Here's a couple of post on the subject:
http://msdn.microsoft.com/en-us/library/bb892960.aspx
http://blogs.msdn.com/b/phkelley/archive/2013/05/29/server-workspaces-vs-local-workspaces.aspx
We're using bower to manage all of our front-end dependencies for our project. I've run into an issue that I think is solvable, but I'm not familiar enough with bower to understand how to do it.
In our project we have one particular dependency that needs to be modified slightly, as in probably 3 lines of code, to meet out project needs. Obviously it's not kosher to edit the file in bower_components directly, but this change needs to be made. What's the best way to go about doing this, and maintaining the dependency tree without having to commit the bower_components.
Understandably we'd have to make a sort of "local copy" of the dependency that we grabbed from Github initially. Any tips?
You could fork it and point to your fork instead or just clone it somewhere locally and point to the local repo.
Bower docs says
N.B. If you aren't authoring a package that is intended to be consumed by others (e.g., you're building a web app), you should always check installed packages into source control.
Does anyone have a good answer to why?
If I am making a web app I don't want my repo cluttered with updates in version of library X.
I just want to update bower.json dependencies. I would think most projects will have a build step or similar, for instance with grunt. The build step would make sure to call bower install/update before building, so that those files are present for concat/minification etc. Or even a plain copy to some dist folder.
Am I missing something?
It's to lock down your dependencies so to prevent a bad dependency from breaking your app or the remote being down preventing deployment. This could happen even though you have a build step, since you probably don't thoroughly test on every build, and automated tests don't catch everything, especially not visual regressions. Also multiple developers might have different versions of a dependency. By having the dependencies committed you ensure everyone stays on the same version. I also find viewing the diff is a good way to ensure nothing malicious was introduced in the dependency tree.
In the Node world npm shrinkwrap partially solves this, but doesn't yet do checksum matching. Bower currently have an open ticket to implement the same.
You can read more about it in this blog post: Checking in front-end dependencies
This answer is non technical but a practical reason to not check in bower components.
I'd rather recommend bower packages to be locked down in bower.json rather than checking in these packages. Because trust me, you cannot have thousands of file downloading and unpacking in a computer. Slow performing computers have a problem with very large and deep file paths. And in this world of internet, I believe it's always easy to download the packages rather than carrying them around.
It is just a matter of preference. It all comes from experience. I have checked in a project with bower components on Github and it is worse while uploading and downloading. I did it through a relatively new Mac.