IDE 1.0.5 does not allow users to update libraries from developers

[drmpf]

Once a library is installed the IDE V1.0.5 does not allow it to be installed again.
Request removing this check

It has been suggested a dialog be opened to alert user the library exists, but I am not sure what this achieves. With no concept of library version nos what is the user expected to do other then alway say overwrite.

Also If touching this function, request that the link between zip name and library name be overridable.

For example if the zip has just a top level directory (or directories) then these should be installed as the libraries. This allows the zip name to include a version number so users can tell which version of the library they are installing.

It also allows multiple libraries to be installed from one zip file.
.eg.
pfodParserLib_V2.zip
contains just
-> pfodParser (dir)
then install pfodParser (dir) under libraries dir

pfodParserLib_V2.zip
contains just
-> pfodParser (dir)
-> pfodCmdParser (dir)
then install pfodParser (dir) and pfodCmdParser (dir) under libraries dir.
i.e. installs two libraries.

For backward compatability, if the top level of the zip file has any non-directory entries then use existing install process which uses the name of the zip as the library name.

[amcewen]

In a similar way to the version number, would it be possible to allow (but strip off) anything after a '-' in the library name?

That would allow library developers to easily package up releases from Github. For example, if you look at https://github.com/amcewen/HttpClient/releases/tag/v2.1 the "Source code (zip)" is created by Github when I create the release, but includes a directory named HttpClient-2.1, so I have to manually add the HttpClient.zip which is the same code but with the "-2.1" removed from the library name so it will install.

It would also allow users to use the "Download ZIP" button on the Github repo's main page. Github names the directory in the zip "-" (so in my HttpClient as an example it would be "HttpClient-master".

[matthijskooijman]

Why do you need the part after the - removed exactly? AFAIU, the Arduino IDE doesn't care how the library directory is called, it just looks at the .h files inside to see which library to use (e.g., if you #include <Foo.h> and a file libraries/Foo-1.2/Foo.h is available, then it should happily include the Foo-1.2 library in the build). Then it actually makes sense to keep the part after the -, so you can later still see which version you installed?

[amcewen]

Having the library version available in the name sounds like a good idea but I think would cause more problems. Which version of Foo.h should the build system include once I've got the Foo-1.2, Foo-1.3 and Foo-3.5 libraries installed? :-)

Sadly dependency management isn't a trivial problem to solve... :-(

[matthijskooijman]

My guess it is will currently just choose the first available version, but I agree that that could be confusing. However, in the recent library format discussion, I suggested to allow the user to choose in case multiple versions are available, which would probably solve this problem (and if that is implemented, implementing the "strip everything after the -" feature now doesn't make sense IMHO).

[pfeerick]

@matthijskooijman The issue with '-' in the filename is because library names (according to the Arduino IDE) are only permitted to have letters and numers - no spaces, and can't start with a number). So the 'add library' function will fail to install the library. If you manually create a library with a hyphen or dash in the name, you'll get the same error when you start the IDE, and the library will be ignored. So at minimum, hyphens/dashes need to be replaced with underscores. And if it is a github repo zip, it makes sense that -master be removed automatically also. However, as you say, it's the name of the .h file that is important for matching, so 'elapsedMills.h' in a elapsedMillis_v1 folder is perfectly valid. However, that leads to the sticky issue of different named folders with the same name .h files in, which the IDE also accepts. 👻 in the IDE, anyone?

Tested on win-Arduino v1.0.5.

[matthijskooijman]

@pfeerick, good point, I didn't consider that. Perhaps allowing dashes in library names makes sense, then?

[pfeerick]

Agreed. Does anyone know why that restriction was put in place?

[cmaglie]

@drmpf the dialog is meant to ask confirm before overwriting an existing library. You may be an expert and know what you are doing, someone else may not and overwriting something without asking may be unexpected.

@pfeerick
Until now the IDE refused names with "-", changing this behaviour to "accept it but strip the name after the -" seems weird and very github-specific (what about other SCM sites? bitbucket? gitorius? another?).
We could change the rule, and simply accept "-" in the name, but this lead (in the github case) to users installing multiple instance of the same library without warnings, and this may lead to even more confusing situations.

[pfeerick]

@cmaglie On windows, there is no dialog (box?) - the space where the compile/upload progress bar normally is turns orange, and the text there says 'a library named xyz already exists' . There are no options, no more information, nothing. Is that the behaviour you're thinking of when you say dialog? As I commented on the mailing list I would have expected a proper prompt (windows ' are you sure you want to?'' style).

btw, bitbucket is even worse for zips - it wacks a '-' and a commit id on the end of the zip name and the zips root folder.

[cmaglie]

@pfeerick
we are talking about a new feature: IDE to allow updating i.e. overwriting, an already installed library. The dialog that I'm talking about is not implemented yet and in my mind is something like what you suggested: "are you sure you want to overwrite XYZ? [Yes] [No]".

C

[drmpf]

Cristian,
My idea was that there would only be one version of the library in the
library path at one time.
The zip file name+version is for developers to keep track of what
version of the library the zip file contains and for the users to
quickly identify if they are accessing the correct zip file.

Once the user has chosen to load that library, I think prompting them
about overwriting is unnecessary.

What is the user expected to do?
If they loading an updated library, then that is what they want to do.
Don't anoy the user, just do what they asked.

If they are reloading an old library (by mistake instead on choosing the
new library zip) then they are expecting to override and existing
library and this dialog does tell them anything new and more importantly
it does not alert them to that problem, since the dialog cannot tell
what the existing installed version is, so no use displaying it.

If they are just reloading an existing library, for the fun of it or by
mistake, then there is no danger, again no use displaying a dialog box.

So my vote is not to display the dialog prompting the use yes or no,
there are too many on those dialogs already in computing and this one
does not add anything useful.

matthew

On 28/11/2013 9:38 PM, Cristian Maglie wrote:

@drmpf the dialog is meant to ask confirm before overwriting an existing library. You may be an expert and know what you are doing, someone else may not and overwriting something without asking may be unexpected.

@pfeerick
Until now the IDE refused names with "-", changing this behaviour to "accept it but strip the name after the -" seems weird and very github-specific (what about other SCM sites? bitbucket? gitorius? another?).
We could change the rule, and simply accept "-" in the name, but this lead (in the github case) to users installing multiple instance of the same library without warnings, and this may lead to even more confusing situations.

---

Reply to this email directly or view it on GitHub:
#1704 (comment)

[Lauszus]

Maybe it it would be a good idea to support periods '.' in directories as well?

[drmpf]

On 28/11/2013 9:38 PM, Cristian Maglie wrote:

@drmpf the dialog is meant to ask confirm before overwriting an existing library. You may be an expert and know what you are doing, someone else may not and overwriting something without asking may be unexpected.

Cristian,
My idea was that there would only be one version of the library in the library path at one time.
The zip file name+version is for developers to keep track of what version of the library the zip file contains and for the users to quickly identify if they are accessing the correct zip file.

Once the user has chosen to load that library, I think prompting them about overwriting is unnecessary.

What is the user expected to do?
If they loading an updated library, then that is what they want to do. Don't annoy the user, just do what they asked.

If they are reloading an old library (by mistake instead on choosing the new library zip) then they are expecting to override an existing library and this dialog does tell them anything new and more importantly it does not alert them to that problem, since the dialog cannot tell what the existing installed version is, so no use displaying the dialog at all.

If they are just reloading an existing library, for the fun of it or by mistake, then there is no danger, again no use displaying a dialog box.

So my vote is not to display the dialog prompting the use yes or no, there are too many on those dialogs already in computing and this one does not add anything useful.

matthew

[matthijskooijman]

I quite disagree: Overwriting a library without prompting a user is bad form if you ask me. Often the user will know what he's doing and intend to overwrite the library, but there will be cases where a user didn't realize they already have the library installed, where he doesn't realize that two seemingly different libraries (for different architectures perhaps) are really the same library, or where he mis-clicks and selects the wrong file.

Offering a choice in a dialog is the proper way to fix this, IMHO.

[pfeerick]

As an advanced user, perhaps not having a warning is plausible. However, I
have yet to see any software just overwrite a pre-existing file or folder
without some form of warning. I know I would curse the soul of any
software developer who did that... After all, why should a new library
overwrite one I have that I may have customised without warning? Anyway,
when the library meta data special and manager are realised, it should be
able to identify and handle upgrade and same-named-but-different libraries
using said meta data.
On 29/11/2013 8:32 pm, "Matthijs Kooijman" notifications@github.com wrote:

I quite disagree: Overwriting a library without prompting a user is bad
form if you ask me. Often the user will know what he's doing and intend to
overwrite the library, but there will be cases where a user didn't realize
they already have the library installed, where he doesn't realize that two
seemingly different libraries (for different architectures perhaps) are
really the same library, or where he mis-clicks and selects the wrong file.

Offering a choice in a dialog is the proper way to fix this, IMHO.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1704#issuecomment-29507940
.