msvc: Fix default MICROPYPATH #1290
Conversation
Default windows installations do not use HOME but USERPROFILE as the environment variable for the user's home directory. Also there is no notion of a common directory like /usr/lib so exclude it from the default path.
That means that "default" Windows is not suitable for more or less advanced usage, so anyone who wants to do that, goes and defines HOME, like it's done on any other system.
Of course there is. You just create it, and put common stuff in there. |
|
An alternative is for windows port to provide its own special getenv and do a translation from HOME to USERPROFILE. What's the default path for CPython? |
Thought of that but then everyone should use some macro like mp_getenv instead of getenv. But maybe it is nicer after all.
Doesn't even include home directory: |
Sure, that's because of differing requirements for CPython and MicroPython. MicroPython, as coming from a git repo, should be usable without requiring root permissions, etc. Note that a distro package would follow different requirement, exactly not having something in ~ by default, so we should make search path compile-time configurable anyway. And what requirements do you follow with this change? Windows being different just for the purpose of being different is easily criticized, per above. |
I mainly want to fix getenv("HOME") already because that is also used in the unix-mp-readline-v2 branch to get the path to the history file, and hence gives me no history at all. |
|
So, the easiest fix for you would be to define HOME. If you want to fix it for other people, then who're these people (different target groups), how they're supposed to use uPy, would they care about such fix at all (maybe one group wouldn't use associated features at all, so won't notice any fixes, and the other can make POSIXish set up anyway), etc. We'd need to answer such questions sooner or later to better support Windows anyway, but if it's not right time and you don't want to consider that, then maybe using existing features as is instead of applying such "spaghetti" patches is suitable alternative for now. |
|
Fair enough, I have HOME and MICROPYPATh defined anyway so don't really care |
Still wanted to comment on this but forgot: it's not as easy as you put it here. Using a single slash at the start of a path will point to the root of the drive of the current working directory. So to get this working reliably (well, sort of) one would for have to make links on each drive to point to one common location. But that is then just for /usr/lib. So in practice it means you just don't use a single slash at the start because you never really know where it's going to end up. Unless you want to rely on cwd but that's a nightmare as well. Or you modify whatever code you use to replace starting |
Yes, so you just stick to one drive. That may seem hard, but using Windows is already pretty hard, so that doesn't change anything much ;-). And it's not that hard actually, because: a) layman users already have a single drive, because that's how vendors usually partition it (and they do it for good reason - to avoid situation when system disk is full and system glitches, while another disk is empty, because user has no idea that it can be used); b) advanced users have >1 drive, but on their experience, use single for "work", like running apps on, and the rest as kind of archives (noexec mount option in unix terms). So, again, it boils down to question whether there's good overall strategy how to deal with Windows support. For example, I hoped - wished - that for a question above you answered: "I'm looking how to make possible (and streamlined) micropython-lib usage on Windows". But you don't, right? Then average users simply won't have any library modules, and all munging with default MICROPYPATH value simply doesn't make much sense. That said, this issue shows some points to work on - make default path configurable via define, perhaps add get_home() function for ports to override. |
But is it really? It simply depends on what you're used to, on what you learned. E.g. I find using OSX hard. Is it hard in general? I doubt it. Would I still find it hard if having used it a couple of months? I doubt it. Likewise I don't find linux hard to use for the things I use it for because I'm used to that. Idem for Windows.
Meh, no :) Maybe they're layman nor advanced but apart from a) and b) (what is ever black and white?) there's a whole lot of other types of users with good reasons to use multiple drives who don't want to adhere to some special, very fragile, rules just to be able to use a forward slash in some program. Instead they will ditch the option of using
There isn't? It's pretty hard to come up with something good when requirements are not known. At least I have no clue of other users nor their usecases.
No because I haven't (yet) had the need for that. And because if I'd had it would still require serious consideration. Lots of interesting stuff in micropython-lib is implemented using libffi to call into libc for instance but there's no such thing on this platform I use so that's facing unknown but likely large amount of time to get that working. |
|
You could take the cygwin approach where they create a pseudo root for each FatFS (used by stmhal) uses drive numbers instead of drive letters and we On Thu, May 28, 2015 at 2:53 AM, stinos notifications@github.com wrote:
Dave Hylands |
|
Such approcahes are indeed feasible since there's a fixed mapping. However I think they always have to be implemented at a low level, like the standard library used, so that every way of talking to the filesystem is covered. So I don't think it's practical for use with uPy on windows (unless I'm missing something, e.g. windows port could supply an implementation for |
|
This is true, and internally the runtime library supports both forward slashed and backward slashes (and thise has been the case since DOS). It's only CMD.EXE/COMMAND.COM and other programs which filter for it which don't like forward slashes (you probably already knew that - but I figured it can't hurt to mention it - just in case) |
|
Yes I'm aware of the limitations, I'm used to using |
Well, I can't put smiley after every word I write ;-). And otherwise I meant "using for development". You don't have standard POSIX API and a lot of other things. On top of that, people try to vary in path separators, paths, etc. But that's not really needed.
Drive letters and forward slashes are orthogonal.
Ok, let them choose and specify MICROPYPATH explicitly. The talk in the original patch was about munging default value. But the default value for Windows cannot be improved. And that's example of those "hard" Windows things. You can't arbitrarily put "C:" for global path - other users may have it on another drive. You cannot use system drive, you cannot use the drive where the executable - all these choices are random and arbitrary. And among all these choices, sticking to concept of current drive as a default is not the worst choice by number of criteria, including ability to use POSIX paths, and even the same values of them as on POSIX system. |
Stating the obvious, libffi also works for Windows (be it mingw or msvc). Yes, underlying API/libraries are different. |
... And the easiest way to achieve that is to build against cygwin. I don't think that uPy should do anything like that, because that's pretty big departure from native Windows way. But using forwards slashes or sticking to current drive are native Windows features OTOH, so using them makes good sense IMHO. |
|
FYI: 51726b4 |
shared-bindings/time: introduce time.monotonic_ns
Default windows installations do not use HOME but USERPROFILE as the environment
variable for the user's home directory. Also there is no notion of a common
directory like /usr/lib so exclude it from the default path.