How can I import subdirectories or files from imported packages that are scoped?
For example I perfectly can do:
import array from "lodash/array".
But as soon as my package is scoped the array.js file (or array/index.js) becomes becomes unavailable, as the following will not work:
import array from "#myscope/lodash/array"
Based on #estus' hint I inspected #angular/common/http (https://github.com/angular/angular/tree/master/packages/common/http) and tried to replicate its file structure and package to understand what's going on.
Apparently You can only deep import from scoped packages with a specific file structure, which is skipping the dist or any other kind of directory that holds Your bundled files. You need to directly have the directory or file You wish to deep import in the scoped package.
Not working example:
node_modules/#angular/common/dist/http/index.js
Here you will not be able to do import http from "#angular/common/http" no matter how you setup your package.jsons. This is the structure I bundled my scoped package into though.
Working example:
node_modules/#angular/common/http/index.js
Here you will be able to do import http from "#angular/common/http". You don't even need a node_modules/#angular/common/http/package.json for that, a node_modules/#angular/common/package.json is sufficient.
Related
I would like to export all my package from one single file, let's say exportAll.js and then across the code I may be able to import the one I need per file using something like
import { package1, package2 } from '../exportAll.js'
However I am concerning about the performance impact. I do believe after once import, Javascript save the reference for future import. However I also believe Javascript will first import all files into exportAll.js when I want to use only package1 and package2 and so, it may slow down the loading process of the first page who import anything from exportAll.
Can you help me to understand if this is bad for performance or even if this is bad practice for any other reason ?
Image
I don't know what am I doing wrong here. I am importing the module from the functions package in the tests package. I tried every method but couldn't solve this problem while I tried to run valid_test.py
You need to use one dot before the functions so the python will know it is in the folder "above" the current location (import statement).
This look like this issue.
When specifying what module to import you do not have to specify the
absolute name of the module. When a module or package is contained
within another package it is possible to make a relative import within
the same top package without having to mention the package name. By
using leading dots in the specified module or package after from you
can specify how high to traverse up the current package hierarchy
without specifying exact names. One leading dot means the current
package where the module making the import exists. Two dots means up
one package level. Three dots is up two levels, etc. So if you execute
from . import mod from a module in the pkg package then you will end
up importing pkg.mod. If you execute from ..subpkg2 import mod from
within pkg.subpkg1 you will import pkg.subpkg2.mod. The specification
for relative imports is contained within PEP 328.
There is another way to solve this issue by adding the "father" folder to the sys.path
by:
import os
import sys
sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__, '..')))
I have been getting the same problem again and again while using SPYDER with anaconda.
I make my own function in other file and import those functions. The code was still not running giving me the error "ModuleNotFoundError: No module named 'my_functions".
I am sure you are selecting lines and executing only selected line only\
Solution to problem is here below
To execute your code as whole/line by line Follow the steps.
Change the working directory of spyder to the folder of current file as here https://pasteboard.co/ee79y0dLqzu4.png .
select lines and execute or you can also execute the whole code.
I want my project to work in two different situations. It should work as a standalone library, but also as sub package of a larger project. The main use case is that of a standalone library, where its internal imports should be of the form
from my_library import sub_package
When using the code as sub package of a larger project, these imports don't work as there is no global name my_library. Instead, I would have to use relative or absolute imports, for example
from large_project.my_library import sub_package
Let's assume I wrote my library as shown in the first example. How can I overwrite importing behavior when running as part of a larger project to automatically adjust import paths?
Thanks to #MatrixTai's suggestion of adding the parent directory of the package to the the module path, I came up with this dynamic solution. At the top of my_library/__init__.py:
# Make package global even if used as a sub package to enable short imports.
import os
import sys
sys.path.append(os.path.dirname(os.path.dirname(__file__)))
We have to navigate up two directories here to do from the my_library/__init__.py to my_library and from there to its parent direction, where imports will find the library.
You don't have much choice.
If you want to reference the my_library.py anywhere, there is 2 method (as I known) can do similar work.
1: add system path. Like those module you installed by pip. pip module is installed in /Python/Scripts. You can add a new path or simply put my_library.py into one of the path. For adding, that's in Computer(right-click)-> Properties -> Environment Variable -> Choose Path and Click Edit
(Though you may not want to use this.)
2: Changing __init__.py, but still at least one line you must add in my_library.py.
For example,
/Directory
/large_project
-__init__.py #call this sub_init
-my_library.py
-__init__.py #call this main_init, this fake
-main.py
In main_init,
import sys
sys.path.append('\\Directory\\large_project')
As main_init is not executed when you execute main.py (this is fake), so in main.py
import __init__
from my_library import sub_package
But as well you can take this main_init as the starter of library, like declaring __all__, etc.
I'm trying to get used to using npm packages brought in to Meteor 1.3 alongside regular Atmosphere packages. I have been able to use the slug package by using
meteor npm install slug
Then in one of my .js files I import slug with this command
import slug from 'slug';
And it seems to work. But it doesn't work when I try it from another .js file. Do I have to put the import command at the top of every file I want to use it in? Is this loading it multiple times in memory?
I'm also changing the default options using
slug.defaults.mode ='rfc3986';
And I'm wondering if I need to put that at the top of all my files as well. Atmosphere packages were a lot simpler. You simply added them and then you could use them throughout the whole project.
If you don't want to repeat the options, use this pattern:
Create a /lib/slug.js in your Meteor project with this content:
import slug from 'slug';
slug.defaults.mode = 'rfc3986';
export default slug;
Then throughout your project do not import slug from 'slug'; but rather import slug from '/lib/slug';.
Yes, you do have to import the module to another module to make it available there. Everything inside the module will not be available to other modules unless you import that module to each module. Please notice the keyword.
Yes you have to import here are some benefits of using imports:
You can control the load order of files by encoding dependencies
through imports.
You can create reusable “modules”.
I wrote a simple set of python3 files for emulating a small set of mongodb features on a 32 bit platform. I fired up PyCharm and put together a directory that looked like:
minu/
client.py
database.py
collection.py
test_client.py
test_database.py
test_client.py
My imports are simple. For example, client.py has the following at the top:
from collection import Collection
Basically, client has a Client class, collection has a Collection class, and database has a Database class. Not too tough.
As long as I cd into the minu directory, I can fire up a python3 interpreter and do things like:
>>> from client import Client
>>> c = Client(pathstring='something')
And everything just works. I can run the test_files as well, which use the same sorts of imports.
I'd like to modularize this, so I can use it another project by just dropping the minu directory alongside my application's .py files and just have everything work. When I do this though, and am running python3 from another directory, the local imports don't work. I placed an empty init.py in the minu directory. That made it so I could import minu. But the others broke. I tried using things like from .collection import Collection (added the dot), but then I can't run things in the original directory anymore, like I could before. What is the simple/right way to do this?
I have looked around a bit with Dr. Google, but none of the examples really clarify it well, feel free to point out the one I missed
In this file ...minu/__init__.py import the submodules you wish to expose externally.
If the __init__.py file contains the following lines, and the client.py file has a variable foo.
import client
import collection
import database
Then from above the minu directory, the following will work:
from minu.client import foo