Strictly speaking that is not what the DataFrames docs say.
I always post with respect for what Julia and the Community is. That said, I do like to convey a sense of urgency when I see it, and I know from experience that in any venture, getting the basics right for the simple things is a “make or break” matter.
I want to see Julia prosper and grow, but I know that will not happen if bugs like this (just simplest reading/writing, standard/common configuration) persist. I have expended quite a bit of energy trying to argue the case for Julia in my institution (with some success), but when students get frustrated by a fundamental unreliability of something very basic like this, it wholly undermines my case for Julia being a sufficiently mature language to adopt, and (in my opinion) at this stage, I find this somewhat alarming, to say the least.
In my opinion there has to be priority placed on the reliability of the basics, no matter how elegant the project wants to ultimately be, or it will have very little chance of succeeding in the long-run.
Another workaround (which I actually like as the main developing workflow for jupyter notebooks) is to use the Jupyter extension inside VSCode, since it does not rely on IJulia, it is able to downgrade
Parsers and it works. You can open your notebooks there.
That sounds like a neat idea. I wasn’t aware until this issue arose that IJulia could break dependencies. It also hadn’t occurred to me that the VSCode approach to Jupyter didn’t require IJulia.
As many folks mentioned already, we generally don’t have these problems in the Julia extension for VS Code, because we load all the packages that the extension needs to function in a non-standard way, so that user code can then load different versions of the same packages and they can co-exist.
That in principle is also true for the new native Jupyter Notebook feature we have in the extension, BUT, I just give a fair warning that this notebook feature in VS Code for Julia is still a bit experimental and new. Because we don’t think we have ironed out all the corner cases yet, we do not enable the feature by default, instead you need to change a configuration setting to get access to the native Jupyter Notebook feature in the Julia extension.
I had originally hoped that we might be able to move out of the experimental mode very soon, but right now it looks like it might take another cycle of upstream releases by VS Code itself (we are waiting for some APIs from them to finish the implementation).
Oh, and one other point: there is also CSVFiles.jl. We use that extensively in my research group and orbit. The package moves relatively slowly in terms of new features etc, for us that kind of stability is important, so that might be another option to try.
I would like to address the “general” point the OP raised, as someone who has worked in the software industry for over 40 years, using countless commercial and open source products across many areas. Here are some rules of thumbs that apply across all software of any type.
- Rule number one of using software is don’t ever upgrade your production environment to the latest version. First test out compatibility in a non production environment.
- When you run across a bug that interferes with your work, spend a bit of your time narrowing down the problem to a small, well documented and replicable case. Try to understand the source of the problem yourself. For commercially supported software this will save you a ton of your own time when working with the paid support team. For open source software, that’s also true but there is an additional reason. Open source projects are usually free and encompass the hard work of many, often unpaid programmers. You need to be respectful of the time of those developers, a basic requirement of human decency.
- Successful open source projects meet 3 criteria: 1. they provide an extremely useful function or set of functionality addressing a problem set faced by a large group of people 2. they take an innovative approach to solving the core problem set, both technologically and in terms of ease of use 3. They have a highly engaged community that builds a large ecosystem around the core tools, consistently adds new innovations and engages with and educates newcomers
I have only recently started learning Julia, and everything I’ve seen so far indicates Julia gets an 11 out of 10 on all three of these criteria. And on point 3, I would add the Julia community is the least divisive and most supportive of any of the new communities I’ve joined over the past 10 years. From past experience, I have a high level of confidence Julia will continue to grow and prosper.
I totally agree, however regarding your first point:
As a new user I find that Julia is pretty happy to update packages and I find it challenging to revert back to the environment I had before (that is, unless I have backed up my Manifest-file, which requires both some proficiency in Julia and some back-up discipline). I am experimenting with using the option
preserve=Pkg.PRESERVE_ALL when adding packages, however I must admit that I don’t yet understand the nuances of the
Perhaps Julia’s default behaviour could be more focused on maintaining a stable environment for new users?
I find it challenging to revert back to the environment I had before
Pkg.undo() not work for you?
(@v1.7) pkg> ?undo undo Undoes the latest change to the active project.
Hi @nilshg ,
Thanks for the suggestion, I will try it out!
PS. In my first try, just now, I am not sure exactly what it undid. The package I added as my last command was for example still in both the project-file and the manifest file.
If there’s anything that doesn’t look right it’s always best to come up with a reproducible example. For package operations I find it convenient to do
]activate --temp to create a throwaway environment, and then step-by-step doing all the package operations which lead to the surprising outcome. There can always be bugs in
Pkg or surprising results coming out of the resolver, so even something seems off it’s good to investigate.
This is of course harder if it’s some old Manifest that you have trouble with, in which case I would probable
Pkg.instantiate() that Manifest (if you have it backed up!), then
add or whatever it is you want to undo, and then
undo. If that doesn’t work then it’d be good to share your Manifest when reporting an issue so that others can reproduce.
Unfortunatly, I cannot seem to reproduce the odd behaviour I saw the first time, I will report it if it happens again! Thanks for your help and great suggestions!
As noted I’m far from a Julia expert. But besides what other people suggested, I can suggest the best way to backup your code and manifests: git along with GitHub or Gitlab which have free versions.
Using git even if you work alone has many benefits, including the ability to revert to working versions and backup via remote providers. When you have a working version, commit everything to git and push to Github/Gitlab so you have a backup. If things get messed up you just use git to revert to the manifest or code file which you know worked. You can easily trace differences in code to find where you went wrong. There are lots of online resources to learn about Git and it’s not hard to learn the basics. I strongly encourage you to try.
3 posts were split to a new topic: Precompile error with DataFrames
2 posts were merged into an existing topic: Precompile error with DataFrames
undo is GREAT ! And for future reference, this also looks helpful here Preserve the state (version) of all existing dependencies (including recursive dependencies)